diff options
Diffstat (limited to 'doc/bugs')
74 files changed, 1421 insertions, 52 deletions
diff --git a/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn new file mode 100644 index 000000000..fbdc58d5d --- /dev/null +++ b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn @@ -0,0 +1,22 @@ +The Atom feed from <http://planet.collabora.co.uk/> +get "double-encoded" (UTF-8 is decoded as Latin-1 and re-encoded as +UTF-8) when aggregated with IkiWiki on Debian unstable. The RSS 1.0 +and RSS 2.0 feeds from the same Planet are fine. All three files +are in fact correct UTF-8, but IkiWiki mis-parses the Atom. + +This turns out to be a bug in XML::Feed, or (depending on your point +of view) XML::Feed failing to work around a design flaw in XML::Atom. +When parsing RSS it returns Unicode strings, but when parsing Atom +it delegates to XML::Atom's behaviour, which by default is to strip +the UTF8 flag from strings that it outputs; as a result, they're +interpreted by IkiWiki as byte sequences corresponding to the UTF-8 +encoding. IkiWiki then treats these as if they were Latin-1 and +encodes them into UTF-8 for output. + +I've filed a bug against XML::Feed on CPAN requesting that it sets +the right magical variable to change this behaviour. IkiWiki can +also apply the same workaround (and doing so should be harmless even +when XML::Feed is fixed); please consider merging my 'atom' branch, +which does so. --[[smcv]] + +[[!tag patch done]] diff --git a/doc/bugs/Allow_overriding_of_symlink_restriction.mdwn b/doc/bugs/Allow_overriding_of_symlink_restriction.mdwn index 07badd646..efdd9004e 100644 --- a/doc/bugs/Allow_overriding_of_symlink_restriction.mdwn +++ b/doc/bugs/Allow_overriding_of_symlink_restriction.mdwn @@ -34,9 +34,9 @@ Is there a huge objection to this patch? index 990fcaa..0fb78ba 100644 --- a/IkiWiki/Render.pm +++ b/IkiWiki/Render.pm - @@ -260,13 +260,15 @@ sub prune ($) { #{{{ + @@ -260,13 +260,15 @@ sub prune ($) { - sub refresh () { #{{{ + sub refresh () { # security check, avoid following symlinks in the srcdir path - my $test=$config{srcdir}; - while (length $test) { @@ -108,7 +108,7 @@ like this being accepted before I bothered. use IkiWiki; +use File::Spec; - sub gen_wrapper () { #{{{ + sub gen_wrapper () { - $config{srcdir}=abs_path($config{srcdir}); - $config{destdir}=abs_path($config{destdir}); - my $this=abs_path($0); diff --git a/doc/bugs/CGI__44___formbuilder__44___non-existent_field_address.mdwn b/doc/bugs/CGI__44___formbuilder__44___non-existent_field_address.mdwn new file mode 100644 index 000000000..ef74deb91 --- /dev/null +++ b/doc/bugs/CGI__44___formbuilder__44___non-existent_field_address.mdwn @@ -0,0 +1,59 @@ +Error received when clicking on the "edit" link: + +> `Error: [CGI::FormBuilder::AUTOLOAD] Fatal: Attempt to address +> non-existent field 'text' by name at +> /home/tealart/bin/share/perl/5.8.4/IkiWiki/CGI.pm line 112` + +Error received when following a "Create New Page" (eg. ?) link: + +> `Error: [CGI::FormBuilder::AUTOLOAD] Fatal: Attempt to address +> non-existent field 'param' by name at +> /home/tealart/bin/share/perl/5.8.4/IkiWiki/Plugin/editpage.pm line 122` + +I could probably find several other flavors of this error if I went +looking, but I trust you get the idea. + +The CGI starts to render (this isn't the "you forgot to set the +permissions/turn on the CGI" error) and then fails. + +Further details: + +- Running on shared hosting (dreamhost; but everything compiles, + dependencies installed, the site generates perfectly, other CGIs + work, the file permissions work). + +- It's running perl 5.8.4, but I did upgrade gettext to 0.17 + +- the server is running gcc v3.3.5 (at this point, this is the main + difference between the working system and my box.) + +- I've removed the locale declarations from both the config file and + the environment variable. + +- I've also modified the page template and have my templates in a non + standard location. The wiki compiles fine, with the template, but + might this be an issue? The CGI script doesn't (seem) to load under + the new template, but I'm not sure how to address this issue. + +- All of the required/suggested module dependencies are installed + (finally) to the latest version including (relevantly) + CGI::FormBuilder 3.0501. + +- I'm running ikiwiki v3.08. Did I mention that it works perfectly in + nearly every other way that I've managed to test thusfar? + +---- + +> I suspect that your perl is too old and is incompatible with the version of CGI::FormBuilder you have installed. +> +> Is so, it seems likely that the same error message can be reproduced by running a simple command like this at the command line: +> +> perl -e 'use warnings; use strict; use CGI::FormBuilder; my $form=CGI::FormBuilder->new; $form->text("boo")' +> +> --[[Joey]] + +> > nope, that command produces no output. :/ +> > +> > I considered downgrading CGI::FormBuilder but I saw evidence of previous versions being incompatible with ikiwiki so I decided against that. +> > +> > -- [[tychoish]] diff --git a/doc/bugs/Can__39__t_create_root_page.mdwn b/doc/bugs/Can__39__t_create_root_page.mdwn index 60cbcd530..91c2eae60 100644 --- a/doc/bugs/Can__39__t_create_root_page.mdwn +++ b/doc/bugs/Can__39__t_create_root_page.mdwn @@ -33,7 +33,7 @@ This type of page name (with leading slash) also gets created by the aggregate p index 99cead6..23d9616 100644 --- a/IkiWiki/CGI.pm +++ b/IkiWiki/CGI.pm - @@ -305,9 +305,11 @@ sub cgi_editpage ($$) { #{{{ + @@ -305,9 +305,11 @@ sub cgi_editpage ($$) { my $page=$form->field('page'); $page=possibly_foolish_untaint($page); if (! defined $page || ! length $page || @@ -46,7 +46,7 @@ This type of page name (with leading slash) also gets created by the aggregate p my $baseurl=$config{url}."/".htmlpage($page); - @@ -425,6 +427,7 @@ sub cgi_editpage ($$) { #{{{ + @@ -425,6 +427,7 @@ sub cgi_editpage ($$) { $from ne $form->field('from') || file_pruned($from, $config{srcdir}) || $from=~/^\// || diff --git a/doc/bugs/Comments_link_is_to_index.html_if_usedirs_is_on.mdwn b/doc/bugs/Comments_link_is_to_index.html_if_usedirs_is_on.mdwn new file mode 100644 index 000000000..6df3ccd9c --- /dev/null +++ b/doc/bugs/Comments_link_is_to_index.html_if_usedirs_is_on.mdwn @@ -0,0 +1,5 @@ +When a page links to its own #comments anchor you get a link like +"index.html#comments" rather than "./#comments". Fixed in commit 0844bd0b +on my 'comments' branch. --[[smcv]] + +[[!tag patch done]] diff --git a/doc/bugs/Error:_Your_login_session_has_expired._.mdwn b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn new file mode 100644 index 000000000..046d6e10d --- /dev/null +++ b/doc/bugs/Error:_Your_login_session_has_expired._.mdwn @@ -0,0 +1,44 @@ +I keep getting: + + Error: Your login session has expired. + +Whilst trying to edit http://hugh.vm.bytemark.co.uk/ikiwiki.cgi via OpenID. Any ideas? + + + iki@hugh:~$ dpkg -l | grep openid + ii libnet-openid-consumer-perl 0.14-4 library for consumers of OpenID iden + tities + iki@hugh:~$ + +> This error occurs if ikiwiki sees something that looks like a CSRF +> attack. It checks for such an attack by embedding your session id on the +> page edit form, and comparing that id with the session id used to post +> the form. +> +> So, somehow your session id has changed between opening the edit form and +> posting it. A few ways this could happen: +> +> * Genuine CSRF attack (unlikely) +> * If you logged out and back in, in another tab, while the edit form was +> open. +> * If `.ikiwiki/sessions.db` was deleted/corrupted while you were in the +> midst of the edit. +> * If some bug in CGI::Session caused your session not to be saved to the +> database somehow. +> * If your browser didn't preserve the session cookie across the edit +> process, for whatever local reason. +> * If you were using a modified version of `editpage.tmpl`, and +> it did not include `FIELD-SID`. +> * If you upgraded from an old version of ikiwiki, before `FIELD-SID` was +> added (<= 2.41), and had an edit form open from that old version, and +> tried to save it using the new. +> +> I don't see the problem editing the sandbox there myself, FWIW. +> (BTW, shouldn't you enable the meta plugin so RecentChanges displays +> better?) +> --[[joey]] + + +Thanks for you excellent analysis. The bug was due to old pre-3.0 **templates** laying about. After deleting them, ikiwiki defaults to its own templates. Clever. :-) + +[[bugs/done]] diff --git a/doc/bugs/Git:_web_commit_message_not_utf-8.mdwn b/doc/bugs/Git:_web_commit_message_not_utf-8.mdwn new file mode 100644 index 000000000..08247dded --- /dev/null +++ b/doc/bugs/Git:_web_commit_message_not_utf-8.mdwn @@ -0,0 +1,17 @@ +The message generated for web commits: + +> web commit by mädduck + +is not utf-8 encoded before passed to Git (which uses utf-8 as default encoding for commit messages). This causes a wrongly-encoded log entry, and makes ikiwiki spew warnings as it creates `recentchanges`: + + utf8 "\xF6" does not map to Unicode at /usr/share/perl5/IkiWiki/Rcs/git.pm line 36, <$OUT> line 57. + Malformed UTF-8 character (unexpected non-continuation byte 0x6e, immediately after start byte 0xf6) in pattern match (m//) at /usr/share/perl5/IkiWiki/Rcs/git.pm line 393. + utf8 "\xF6" does not map to Unicode at /usr/share/perl5/IkiWiki/Rcs/git.pm line 36, <$OUT> line 5. + +(This is version 2.53.3~bpo40+1 for lack of a newer backport for sarge) + +Please make sure that commit messages for Git are always utf-8. + +This is a change by user `mädduck` to trigger the error. + +> [[Fixed|done]] both on the commit and log sides. --[[Joey]] diff --git a/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn b/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn new file mode 100644 index 000000000..1d396c85b --- /dev/null +++ b/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn @@ -0,0 +1,24 @@ +'make test' has the following errors: + +Can't locate Locale/gettext.pm in @INC (@INC contains: /home/turian/utils//lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /home/turian/utils//lib/perl5/site_perl/5.8.8 . /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8) at (eval 254) line 2. + +What's weird is that I already have gettext.pm: + /home/turian/utils/lib/perl5/lib/i386-linux-thread-multi/Locale/gettext.pm + +That directory should be part of @INC, because I have: + export PERL5LIB="$PERL5LIB:$UTILS/lib/perl5/lib/i386-linux-thread-multi/" +in my .bashrc. However, /home/turian/utils/lib/perl5/lib/i386-linux-thread-multi/ does not appear in that @INC line. + +How do I get the proper @INC locations set? + +> Nothing in ikiwiki touches whatever PERL5DIR setting you may have, +> so AFAICS, this must be some sort of local configuration problem. +> How do +> `/home/turian/utils//lib/perl5/site_perl/5.8.8/i386-linux-thread-multi` +> and `/home/turian/utils//lib/perl5/site_perl/5.8.8` get into the +> displayed `@INC`? The likely way seems to be that something in your +> system sets PERL5LIB to contain those directories, clobbering +> the earlier setting in your `.bashrc`. +> --[[Joey]] + +[[!tag done]] diff --git a/doc/bugs/IkiWiki::Wrapper_should_use_destdir.mdwn b/doc/bugs/IkiWiki::Wrapper_should_use_destdir.mdwn new file mode 100644 index 000000000..6b02c4186 --- /dev/null +++ b/doc/bugs/IkiWiki::Wrapper_should_use_destdir.mdwn @@ -0,0 +1,23 @@ +In IkiWiki/Wrapper.pm, the gen_wrapper function finds out what srcdir and +destdir are set to in the config, but does not use them. + +Later in the sub, when a new wiki.cgi wrapper is being created when calling +ikiwiki --setup /path/to/setup, it will only work if cgi\_wrapper in the +config file is set to the full path. Otherwise, it creates wiki.cgi in the +current working directory. It works with the other wrapper it sets up in +my config - post\_update (using git), as that shows in the config with a +full path. + +One workaround would be to mention in the setup file that cgi_wrapper has +to be the full path, not just the file name, but that seems silly when +destdir is also specified in that file and that's where it should go, and +$config{destdir} is a known value in the Wrapper.pm file. + +> Nowhere in any documentation does +> it say that cgi\_wrapper is relative to the destdir. +> As noted in [[discussion]], there are web server setups +> that require the cgi be located elsewhere. +> [[done]] --[[Joey]] + +>> A comment in the generated setup file that all paths should be full +>> would prevent my (admittedly dumb) error without any drawbacks. diff --git a/doc/bugs/IkiWiki::Wrapper_should_use_destdir/discussion.mdwn b/doc/bugs/IkiWiki::Wrapper_should_use_destdir/discussion.mdwn new file mode 100644 index 000000000..870fa7a66 --- /dev/null +++ b/doc/bugs/IkiWiki::Wrapper_should_use_destdir/discussion.mdwn @@ -0,0 +1,4 @@ +Just as a point of information, I do not put my cgi wrapper in the dest +directory. Instead I configure Apache to relate a specific URI to the cgi via +ScriptAlias. I would not like things to be changed so that the cgi was put in +the destdir, so I'd vote instead to comment in the `setup\_file`. -- [[Jon]] diff --git a/doc/bugs/Insecure_dependency_in_eval_while_running_with_-T_switch.mdwn b/doc/bugs/Insecure_dependency_in_eval_while_running_with_-T_switch.mdwn index 28b48e2c6..c3beb8219 100644 --- a/doc/bugs/Insecure_dependency_in_eval_while_running_with_-T_switch.mdwn +++ b/doc/bugs/Insecure_dependency_in_eval_while_running_with_-T_switch.mdwn @@ -53,7 +53,7 @@ I didn't apply your following old patch against `Ikiwiki.pm` file: + } + + return eval $newpagespec; - } #}}} + } package IkiWiki::PageSpec; @@ -83,7 +83,7 @@ to break the code I distribute in my backport ;) + my $ret=eval possibly_foolish_untaint(pagespec_translate($spec)); return IkiWiki::FailReason->new("syntax error") if $@; return $ret; - } #}}} + } >> Thanks a lot, Joey! It works :) >> diff --git a/doc/bugs/Meta_plugin_does_not_respect_htmlscrubber__95__skip_setting.___40__patch__41__.mdwn b/doc/bugs/Meta_plugin_does_not_respect_htmlscrubber__95__skip_setting.___40__patch__41__.mdwn new file mode 100644 index 000000000..0e40da551 --- /dev/null +++ b/doc/bugs/Meta_plugin_does_not_respect_htmlscrubber__95__skip_setting.___40__patch__41__.mdwn @@ -0,0 +1,11 @@ +I have been trying to include some meta info using the link setting something like the below + + meta link="http://www.example.com/" rel="command" name="Example" + +This gets removed by the htmlscrubber as you would expect. + +Setting htmlscrubber_skip to the pagespec should stop this getting scrubbed but it does not. + +Below is a patch to fix that. It seams to work but I am not sure of it is the correct thing to do. + +> [[done]], thanks for the patch --[[Joey]] diff --git a/doc/bugs/Monotone_rcs_support.mdwn b/doc/bugs/Monotone_rcs_support.mdwn index 3d1388312..8687e7983 100644 --- a/doc/bugs/Monotone_rcs_support.mdwn +++ b/doc/bugs/Monotone_rcs_support.mdwn @@ -11,7 +11,7 @@ diff --git a/IkiWiki/Rcs/monotone.pm b/IkiWiki/Rcs/monotone.pm index cde6029..34f8f96 100644 --- a/IkiWiki/Rcs/monotone.pm +++ b/IkiWiki/Rcs/monotone.pm -@@ -186,8 +186,9 @@ sub rcs_update () { #{{{ +@@ -186,8 +186,9 @@ sub rcs_update () { check_config(); if (defined($config{mtnsync}) && $config{mtnsync}) { diff --git a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn index 019970899..bb3f92f9c 100644 --- a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn +++ b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn @@ -38,19 +38,19 @@ At the moment I see two possible solutions: +++ IkiWiki.pm 2008-07-21 20:41:35.000000000 +0200 @@ -477,13 +477,13 @@ - sub titlepage ($) { #{{{ + sub titlepage ($) { my $title=shift; - $title=~s/([^-[:alnum:]:+\/.])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; + $title=~s/([^-[:alnum:]+\/.])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; return $title; - } #}}} + } - sub linkpage ($) { #{{{ + sub linkpage ($) { my $link=shift; - $link=~s/([^-[:alnum:]:+\/._])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; + $link=~s/([^-[:alnum:]+\/._])/$1 eq ' ' ? '_' : "__".ord($1)."__"/eg; return $link; - } #}}} + } What do you think about that? Does the patch have any side-effects I didn't see? diff --git a/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn b/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn new file mode 100644 index 000000000..0a1299993 --- /dev/null +++ b/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn @@ -0,0 +1,25 @@ +If a PNG image matches the [[ikiwiki/PageSpec]] of an [[ikiwiki/directive/inline]] directive, the page throws the following error: + +> \[[!inline Error: Malformed UTF-8 character (fatal) at /usr/local/lib/perl5/site_perl/5.8.8/File/MimeInfo.pm line 120.]] + +Individual posts display fine, and moving the offending image outside the scope of the [[ikiwiki/directive/inline]] directive's PageSpec eliminates the error. + +> I tried to reproduce this with a random png and File::MimeInfo +> version 0.15, but could not. The png was included in the generated feed +> via an enclosure, as it should be; no warnings or errors. +> +> Looking at the source to File::MimeInfo and its changelog, +> I'm pretty sure that this problem was fixed in version +> 0.14: +>> - Fixed bug with malformed utf8 chars in default() method +> +> The code involved in that fix looks like this: +> +>> no warnings; # warnings can be thrown when input not ascii +>> if ($] < 5.008 or ! utf8::valid($line)) { +>> use bytes; # avoid invalid utf8 chars +> +> I guess that your locally installed version of File::MimeInfo is older than +> this. So closing this bug [[done]]. If you still see the problem with a current +> version of File::MimeInfo, please reopen and include where I can get a png file +> that triggers the problem. --[[Joey]] diff --git a/doc/bugs/Problem_with_toc.pm_plug-in.mdwn b/doc/bugs/Problem_with_toc.pm_plug-in.mdwn index 8ae347d42..6be5f89b5 100644 --- a/doc/bugs/Problem_with_toc.pm_plug-in.mdwn +++ b/doc/bugs/Problem_with_toc.pm_plug-in.mdwn @@ -9,7 +9,7 @@ Here is a patch for toc.pm for producing non-empty 'a' elements. --- IkiWiki/Plugin/toc.pm.orig Thu Jun 7 11:53:53 2007 +++ IkiWiki/Plugin/toc.pm Thu Jun 7 13:00:00 2007 - @@ -47,7 +47,7 @@ sub format (@) { #{{{ + @@ -47,7 +47,7 @@ sub format (@) { if ($tagname =~ /^h(\d+)$/i) { my $level=$1; my $anchor="index".++$anchors{$level}."h$level"; @@ -18,7 +18,7 @@ Here is a patch for toc.pm for producing non-empty 'a' elements. # Take the first header level seen as the topmost level, # even if there are higher levels seen later on. - @@ -90,6 +90,16 @@ sub format (@) { #{{{ + @@ -90,6 +90,16 @@ sub format (@) { "</a>\n"; $p->handler(text => undef); }, "dtext"); diff --git a/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn b/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn index 9a26e505a..c9f698158 100644 --- a/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn +++ b/doc/bugs/Problems_with_graphviz.pm_plug-in.mdwn @@ -15,7 +15,7 @@ It also generates image URLs relative to the page being rendered, which means th --- 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 (\%) { #{{{ + @@ -69,7 +69,12 @@ sub render_graph (\%) { } } @@ -26,9 +26,9 @@ It also generates image URLs relative to the page being rendered, which means th + else { + return "<img src=\"".urlto($dest, $params{page})."\" />\n"; + } - } #}}} + } - sub graph (@) { #{{{ + sub graph (@) { >> --[[HenrikBrixAndersen]] @@ -38,7 +38,7 @@ The patch below fixes these two issues. --- graphviz.pm.orig Thu Jun 7 15:45:16 2007 +++ graphviz.pm Fri Jun 8 12:03:38 2007 - @@ -41,7 +41,6 @@ sub render_graph (\%) { #{{{ + @@ -41,7 +41,6 @@ sub render_graph (\%) { $pid=open2(*IN, *OUT, "$params{prog} -Tpng"); # open2 doesn't respect "use open ':utf8'" @@ -46,7 +46,7 @@ The patch below fixes these two issues. binmode (OUT, ':utf8'); print OUT $src; - @@ -70,7 +69,12 @@ sub render_graph (\%) { #{{{ + @@ -70,7 +69,12 @@ sub render_graph (\%) { } } @@ -57,6 +57,6 @@ The patch below fixes these two issues. + else { + return "<img src=\"".urlto($dest, $params{page})."\" />\n"; + } - } #}}} + } - sub graph (@) { #{{{ + sub graph (@) { diff --git a/doc/bugs/RecentChanges_broken_with_empty_svnpath.mdwn b/doc/bugs/RecentChanges_broken_with_empty_svnpath.mdwn index 836c39a71..c852df5e9 100644 --- a/doc/bugs/RecentChanges_broken_with_empty_svnpath.mdwn +++ b/doc/bugs/RecentChanges_broken_with_empty_svnpath.mdwn @@ -13,7 +13,7 @@ I can not see why this check is needed in the first place, so here's a patch for diff -upr ikiwiki-1.49.orig/IkiWiki/Rcs/svn.pm ikiwiki-1.49/IkiWiki/Rcs/svn.pm --- ikiwiki-1.49.orig/IkiWiki/Rcs/svn.pm Mon Apr 16 15:15:09 2007 +++ ikiwiki-1.49/IkiWiki/Rcs/svn.pm Mon Apr 16 15:15:47 2007 - @@ -176,7 +176,6 @@ sub rcs_recentchanges ($) { #{{{ + @@ -176,7 +176,6 @@ sub rcs_recentchanges ($) { } foreach (keys %{$logentry->{paths}}) { diff --git a/doc/bugs/SVG_files_not_recognized_as_images.mdwn b/doc/bugs/SVG_files_not_recognized_as_images.mdwn new file mode 100644 index 000000000..207edd426 --- /dev/null +++ b/doc/bugs/SVG_files_not_recognized_as_images.mdwn @@ -0,0 +1,29 @@ +In ikiwiki 2.66, SVG images are not recognized as images. In ikiwiki.pm, +the hardcoded list of image file extensions does not include ".svg", which +it probably should unless there's some other issue about rendering SVGs? + +The 'img' plugin also seems to not support SVGs. + +> SVG images can only be included via an `<object>`, `<embed>`, or +> `<iframe>` tag. Or, perhaps as [inline SVG](http://wiki.svg.org/Inline_SVG). +> The [[plugins/htmlscrubber]] strips all three tags since they can easily +> be used maliciously. If doing inline SVG, I'd worry that the svg file +> could be malformed and mess up the html, or even inject javascript. So, +> the only options seem to be only supporting svgs on wikis that do not +> sanitize their html, or assuming that svgs are trusted content and +> embedding them inline. None of which seem particularly palatable. +> +> I suppose the other option would be converting the svg file to a static +> image (png). The img plugin could probably do that fairly simply. +> --[[Joey]] + +>> I'm working on inline SVG and MathML support in ikiwiki and I've +>> modified my htmlscrubber to sanitize SVG and MathML using the +>> whitelists from html5lib. Here's a [patch][]. I've also made some +>> notes about this here: [[todo/svg]]. +>> +>> I suspect that this bug may have caught the eye of anyone interested +>> in this sort of thing. I'll elaborate a bit on my user page to avoid +>> getting off-topic here. --[[JasonBlevins]], October 21, 2008 + + [patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073 diff --git a/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn b/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn index f6dbacad7..8aea5cd29 100644 --- a/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn +++ b/doc/bugs/Spaces_in_link_text_for_ikiwiki_links.mdwn @@ -44,7 +44,7 @@ reported in [[index/discussion#index11h1]]. >> >> If there was ever a future, syntax-breaking major release of ikiwiki >> (similar to python3000) I'd like to see this fixed as part of that. ->> --[[JonDowland]] +>> --[[users/Jon]] >>> You can enable `prefix_directives` and get the disambiguated behavior >>> and spaces in wikilinks today. It will become the default in 3.0. diff --git a/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn b/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn index cc53c0aea..f2c60309b 100644 --- a/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn +++ b/doc/bugs/Titles_are_lower-cased_when_creating_a_page.mdwn @@ -6,7 +6,7 @@ If I click on "Czars in Russia", I'd like Ikiwiki to create "Czars\_in\_Russia.m > --- a/IkiWiki.pm > +++ b/IkiWiki.pm -> @@ -584,7 +584,7 @@ sub htmllink ($$$;@) { #{{{ +> @@ -584,7 +584,7 @@ sub htmllink ($$$;@) { > return "<span class=\"createlink\"><a href=\"". > cgiurl( > do => "create", diff --git a/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn b/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn new file mode 100644 index 000000000..59b67d493 --- /dev/null +++ b/doc/bugs/URLs_with_parentheses_displayed_badly.mdwn @@ -0,0 +1,19 @@ +I've noticed that Ikiwiki displays URLs with parentheses badly. The problem occurs +in the latest version 3.00 and older versions. Please look at the link to following +Polish entry about C programming language at Wikipedia (it seems that URLs with +parentheses are popular there): + +[Język programowania C](http://pl.wikipedia.org/wiki/C_(j%C4%99zyk_programowania)) + +I need to escape a closing parenthesis of the URL to fix the problem. + +[Język programowania C](http://pl.wikipedia.org/wiki/C_(j%C4%99zyk_programowania\)) + +--[[Paweł|users/ptecza]] + +> This is a bug in markdown version 1. It is fixed in [[!cpan Text::Markdown]], +> which ikiwiki will use if it's installed. [[done]] --[[Joey]] + +>> Thanks a lot for the hint, Joey! I've installed `libtext-markdown-perl` package +>> (Aptitude has removed `markdown` package to satisfy dependencies) and now +>> I don't need to escape Wikipedia URLs with parentheses :) --[[Paweł|users/ptecza]] diff --git a/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn b/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn index 88a187dfc..12c0ad07f 100644 --- a/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn +++ b/doc/bugs/Use_install__40__1__41___instead_of_cp__40__1__41___for_installing_files.mdwn @@ -24,4 +24,9 @@ Here is a patch against ikiwiki-1.51 for using find(1) and install(1) instead of >> No, apparently FreeBSD `install` does not support `-D`. See [the FreeBSD install manpage](http://www.freebsd.org/cgi/man.cgi?query=install&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html). --[[JoshTriplett]] ->> Patch applied; [[bugs/done]]. --[[JoshTriplett]] +>> Patch applied; [[done]]. --[[JoshTriplett]] + +There are still/again "cp -a"s in the Makefile as of 3.00 + +> It's a cp -a || install. Is that causing you a problem somehow? +> --[[Joey]] diff --git a/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn b/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn index a30f110a4..efb5c70b8 100644 --- a/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn +++ b/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn @@ -6,7 +6,7 @@ In `IkiWiki::preprocess`, the last capturing group in the regex used to parse di index 241a7c0..d2c35a2 100644 --- a/IkiWiki.pm +++ b/IkiWiki.pm - @@ -1167,7 +1167,8 @@ sub preprocess ($$$;$$) { #{{{ + @@ -1167,7 +1167,8 @@ sub preprocess ($$$;$$) { }sx; } @@ -14,6 +14,6 @@ In `IkiWiki::preprocess`, the last capturing group in the regex used to parse di + # $4 can be undef if the directive was \[[!foo]] + $content =~ s{$regex}{$handle->($1, $2, $3, ($4 or ""))}eg; return $content; - } #}}} + } [[cherry-picked|done]] --[[Joey]] diff --git a/doc/bugs/basewiki_uses_meta_directives_but_meta_is_not_enabled_by_default.mdwn b/doc/bugs/basewiki_uses_meta_directives_but_meta_is_not_enabled_by_default.mdwn new file mode 100644 index 000000000..62931d8bc --- /dev/null +++ b/doc/bugs/basewiki_uses_meta_directives_but_meta_is_not_enabled_by_default.mdwn @@ -0,0 +1,5 @@ +[[plugins/meta]] is not enabled by default, yet some pages in the default basewiki include [[the_meta_directive|ikiwiki/directive/meta]], notably the [[ikiwiki]] heirarchy. + +This means that the default output of "ikiwiki src dest", for two empty directories src and dest, result in the meta directive being displayed inline with the page text. + +> [[done]], meta now enabled by default. diff --git a/doc/bugs/beautify__95__urlpath_will_add_.__47___even_if_it_is_already_present.mdwn b/doc/bugs/beautify__95__urlpath_will_add_.__47___even_if_it_is_already_present.mdwn new file mode 100644 index 000000000..8e96b1f56 --- /dev/null +++ b/doc/bugs/beautify__95__urlpath_will_add_.__47___even_if_it_is_already_present.mdwn @@ -0,0 +1,3 @@ +beautify_urlpath will prepend a useless "./" to the URL "./foo". Fixed in commit 5b1cf21a on my comments branch. --[[smcv]] + +[[!tag patch done]] diff --git a/doc/bugs/bugfix_for:___34__mtn:_operation_canceled:_Broken_pipe__34_____40__patch__41__.mdwn b/doc/bugs/bugfix_for:___34__mtn:_operation_canceled:_Broken_pipe__34_____40__patch__41__.mdwn new file mode 100644 index 000000000..b7f38fd29 --- /dev/null +++ b/doc/bugs/bugfix_for:___34__mtn:_operation_canceled:_Broken_pipe__34_____40__patch__41__.mdwn @@ -0,0 +1,24 @@ +When using monotone as revision control system, a "mtn: operation canceled: Broken pipe" message is printed. Reason is that, in a call to mtn, the pipe is closed before mtn has done all its output. This patch fixes the problem. + + diff -up ikiwiki/IkiWiki/Plugin/monotone.pm.orig ikiwiki/IkiWiki/Plugin/monotone.pm + --- ikiwiki/IkiWiki/Plugin/monotone.pm.orig 2008-11-12 23:45:24.000000000 +0100 + +++ ikiwiki/IkiWiki/Plugin/monotone.pm 2008-12-16 12:41:38.000000000 +0100 + @@ -525,13 +525,12 @@ sub rcs_recentchanges ($) { + my $child = open(MTNLOG, "-|"); + if (! $child) { + exec("mtn", "log", "--root=$config{mtnrootdir}", "--no-graph", + - "--brief") || error("mtn log failed to run"); + + "--brief", "--last=$num") || error("mtn log failed to run"); + } + + - while (($num >= 0) and (my $line = <MTNLOG>)) { + + while (my $line = <MTNLOG>) { + if ($line =~ m/^($sha1_pattern)/) { + push @revs, $1; + - $num -= 1; + } + } + close MTNLOG || debug("mtn log exited $?"); + +> Thanks for the patch, and for testing the monotone backend. +> applied [[done]] --[[Joey]] diff --git a/doc/bugs/bzr_RecentChanges_dates_start_from_1969.mdwn b/doc/bugs/bzr_RecentChanges_dates_start_from_1969.mdwn new file mode 100644 index 000000000..fa6e45b47 --- /dev/null +++ b/doc/bugs/bzr_RecentChanges_dates_start_from_1969.mdwn @@ -0,0 +1,16 @@ +Using bzr, the dates for changes on the RecentChanges page all start +slightly before the Unix epoch. + +Changing line 249 of bzr.pm from + +` when => time - str2time($info->{"timestamp"}),` + +to + +` when => str2time($info->{"timestamp"}),` + +fixed this for me. + +> Weird, I wonder why it was written to return an absolute time like that +> in the first place? Can't have ever been right. Fixed, thanks. --[[Joey]] +> [[done]] diff --git a/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn b/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn new file mode 100644 index 000000000..0294ec62e --- /dev/null +++ b/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn @@ -0,0 +1,27 @@ +The bzr plugin does not seem to define the rcs_diff subroutine. +I got the follow error after enabling recentchangesdiff: + +"Undefined subroutine &IkiWiki::Plugin::bzr::rcs_diff called at /usr/share/perl5/IkiWiki.pm line 1590." + +Grepping to verify absence of rcs_diff: + + $ grep rcs_diff /usr/share/perl5/IkiWiki/Plugin/{git,bzr}.pm + /usr/share/perl5/IkiWiki/Plugin/git.pm: hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff); + /usr/share/perl5/IkiWiki/Plugin/git.pm:sub rcs_diff ($) { + /usr/share/perl5/IkiWiki/Plugin/bzr.pm: hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff); + +> I've added the minimal stub needed to avoid the crash, but for +> recentchangesdiff to work, someone needs to implement `rcs_diff` for bzr. +> This should be trivial if you know and use bzr. The function +> is passed as a parameter the revno of interest and just needs +> to ask bzr for the diff between that and the previous version. --[[Joey]] + +>> I'll see if I can make a patch. The bzr command to get the revision would +>> look like this: bzr diff -r revno:$PREV:/path/to/src..revno:$REVNO:/path/to/src +>> (where $PREV would be $REVNO minus one). --liw + +>> Sorry, that was not entirely correct, for some reason. I'll add a patch below that +>> seems to work. I am unfortunately not ready to set up a git repository that you +>> can pull from. --liw + +[[done]] --[[Joey]] diff --git a/doc/bugs/cannot_preview_shortcuts.mdwn b/doc/bugs/cannot_preview_shortcuts.mdwn new file mode 100644 index 000000000..d7045b2dc --- /dev/null +++ b/doc/bugs/cannot_preview_shortcuts.mdwn @@ -0,0 +1,17 @@ +Shortcuts such as \[[!google foo]] do not work when previewing pages. +--[[JasonBlevins]] + +> Broken during the setup dumping changes, now fixed. --[[Joey]] [[done]] + +>> Just a quick note that this fix interacts with the way the `listdirectives` +>> directive gets its list of non-shortcut directives. At the moment it +>> still works, but it relies on the fact that the `listdirectives` `checkconfig` +>> hook is called before the `shortcut` `checkconfig` hook. +>> -- [[Will]] + +>> The order plugins are loaded is effectively random. (`keys %hooks`). +>> So I've made shortcuts pass a 'shortcut' parameter when registering +>> them, which listdirectives can grep out of the full list of directives. +>> That may not be the best name to give it, especially if other plugins +>> generate directives too. Seemed better than forcing shortcut's +>> checkconfig hook to run last tho. --[[Joey]] diff --git a/doc/bugs/cannot_reliably_use_meta_in_template.mdwn b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn new file mode 100644 index 000000000..de6c227f6 --- /dev/null +++ b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn @@ -0,0 +1,18 @@ +meta title cannot reliably be put inside a template used by the +[[plugins/template]] plugin. Since meta title info is gathered in the scan +pass, which does not look at the template a page includes, it will not be +seen then, and so other pages that use the page title probably won't use +it. (Barring luck with build order.) + +Update: This also affects using tags from templates. + +There is a simple fix for this, just add `scan => 1` when registering the +preprocess hook for the template plugin. + +However, the overhead of this has to be considered. It means that, on every +scan pass, every page containing a template will cause the template to be +loaded and filled out. This can be some serious additional overhead. + +--[[Joey]] + +[[done]] diff --git a/doc/bugs/comments_produce_broken_links_in_RecentChanges.mdwn b/doc/bugs/comments_produce_broken_links_in_RecentChanges.mdwn new file mode 100644 index 000000000..dae00857b --- /dev/null +++ b/doc/bugs/comments_produce_broken_links_in_RecentChanges.mdwn @@ -0,0 +1,9 @@ +Comments produce links like `sandbox/comment_1` in [[RecentChanges]], which, +when clicked, redirect to a page that does not exist. + +The `recentchanges` branch in my repository contains one possible [[patch]], +which causes the CGI to go to the [[ikiwiki/directive/meta]] `permalink`, if +any, if the page is internal (comments do have a permalink). + +> [[done]].. I I had thought about not showing internal page changes at +> all, but I like your approach better --[[Joey]] diff --git a/doc/bugs/disabling_backlinks.mdwn b/doc/bugs/disabling_backlinks.mdwn index ba96a4e2b..415708a50 100644 --- a/doc/bugs/disabling_backlinks.mdwn +++ b/doc/bugs/disabling_backlinks.mdwn @@ -28,3 +28,5 @@ auto-generated index is insufficient. > tagged, I think you have larger problems than tags and backlinks being > the same. Like keeping that list of links up to date as tags are added > and changed. --[[Joey]] + +I see your point, Joey. I need to maintain that list manually, though, because the automatically generated list is too brief. \[[!map ...]] generates just a list of titles or descriptions. I need a list that contains both. See [[this_posting|ikiwiki/directive/map/discussion]] for more details. Until \[[!map]] can do that, I'm stuck with a manually maintained list. Which means that every link shows up in the backlinks. diff --git a/doc/bugs/dumpsetup_does_not_save_destdir.mdwn b/doc/bugs/dumpsetup_does_not_save_destdir.mdwn new file mode 100644 index 000000000..768c3fc5e --- /dev/null +++ b/doc/bugs/dumpsetup_does_not_save_destdir.mdwn @@ -0,0 +1,3 @@ +Calling ikiwiki with a bunch of options, including the --dumpsetup somefile.setup option creates somefile.setup for later reuse with the --setup option. The destination dir however is not saved in the setup file, it has destdir => ''. + +> that broke in version 2.64 .. fixed [[done]] --[[Joey]] diff --git a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn index 012fcec2c..02ce4e221 100644 --- a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn +++ b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn @@ -3,8 +3,8 @@ matches all other pages, including all internal pages. This can lead to unexpected results, since it will match a bunch of recentchanges pages, etc. -Recall that internal-use pages are not matched by a glob. So "*" doesn't -match them. So if the pagespec is "* and !foo and !bar", it won't match +Recall that internal-use pages are not matched by a glob. So "\*" doesn't +match them. So if the pagespec is "\* and !foo and !bar", it won't match them. This is the much more common style. There's an odd inconsistency with entirely negated pagespecs. If "!foo" diff --git a/doc/bugs/feedfile_does_the_wrong_thing_from_index.mdwn2.mdwn b/doc/bugs/feedfile_does_the_wrong_thing_from_index.mdwn2.mdwn new file mode 100644 index 000000000..6b8781a8c --- /dev/null +++ b/doc/bugs/feedfile_does_the_wrong_thing_from_index.mdwn2.mdwn @@ -0,0 +1,7 @@ +[[!meta title="feedfile does the wrong thing from index"]] + +When I put the following !inline in my index.mdwn, it generate a file called index/graphics.rss. However, the link in the RSS button is to graphics.rss (i.e., not in the index/ directory). + +`\[[!inline pages="link(tags/graphics) and ./posts/* and !*/Discussion" show="10" feedfile=graphics feedonly=yes]]` + +[[done]] --[[Joey]] diff --git a/doc/bugs/git_stderr_output_causes_problems.mdwn b/doc/bugs/git_stderr_output_causes_problems.mdwn index 4146a5869..c25ef6927 100644 --- a/doc/bugs/git_stderr_output_causes_problems.mdwn +++ b/doc/bugs/git_stderr_output_causes_problems.mdwn @@ -6,7 +6,7 @@ Ikiwiki's git handling is sending a bunch of output to stderr. The following pa index 425536f..5734bb2 100644 --- a/IkiWiki/Rcs/git.pm +++ b/IkiWiki/Rcs/git.pm - @@ -24,6 +24,7 @@ sub _safe_git (&@) { #{{{ + @@ -24,6 +24,7 @@ sub _safe_git (&@) { if (!$pid) { # In child. # Git commands want to be in wc. diff --git a/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn b/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn index c465bdd4a..564982ff3 100644 --- a/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn +++ b/doc/bugs/gitweb_deficiency_w.r.t._log_messages.mdwn @@ -8,3 +8,7 @@ cases of the one which was installed directly before the current commit. > I don't see one, except for diffs that show all changes in the commit, > rather than only changes to a single file. This feels like a bug in > gitweb. --[[Joey]] + +This is fixed by using the new gitweb style urls. Which new gitweb +requires, but is a manual change you have to make in your setup. So, +[[done]] --[[Joey]] diff --git a/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn b/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn index 255d9cee7..0b4d70596 100644 --- a/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn +++ b/doc/bugs/gitweb_deficiency_w.r.t._newly_created_pages.mdwn @@ -8,3 +8,6 @@ Going from *RecentChanges*, when viewing the diffs of newly created pages > I don't see any way to make gitweb do that. You can click on the filename > after the "diff -cc" to see the whole file output, but gitweb won't show > a diff for a newly added file. --[[Joey]] + +>> happily this, too, is fixed by using the new style gitweb urls. [[done]] +>> --[[Joey]] diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn new file mode 100644 index 000000000..41f955e51 --- /dev/null +++ b/doc/bugs/html5_support.mdwn @@ -0,0 +1,47 @@ +Some elements of [HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/) can be safely supported by ikiwiki. There are [several differences between HTML4 and HTMl5](http://www.w3.org/TR/html5-diff/). Unsupported new elements _should degrade gracefully_. + +> In the `origin/html` branch, there is an old work in progress to make +> ikiwiki use html 4 instead of xhtml. If that could be brought forward and +> finished then the plan has been to switch ikiwiki over to doing html 4. +> I don't think it makes sense to try to make it support both xhtml and +> html, it would complicate the code for no benefit. +> +> I think that is the best route toward supporting html 5 as well. Get +> ikiwiki doing html 4 first and the changes needed to get to 5 from there +> should be small. Probably just changing some doctypes and a few other +> small changes which could be kept in a branch, or even shipped in ikiwiki +> mainline as an alternate set of templates. Some of the changes, like +> supporting new html 5 tags in the htmlscrubber, can be done in mainline. +> (Like was already done for the html 5 video and audio tags.) +> +> This approach seems much more maintainable going foward than rolling a +> html 5 branch immediatly and trying to keep that continually up-to-date +> with mainline ikiwiki that is still using xhtml. --[[Joey]] + +However as an [early adopter](http://en.wikipedia.org/wiki/Early_adopter) I would like to start using HTML5 as much as possible. The more pragmatic solution would be to use elements supported by the browsers of your readership I guess. I'm following other early adopters like [Anne](http://annevankesteren.nl/) for clues on how to proceed. + +* [Initial patch](http://git.webconverger.org/?p=ikiwiki;a=commit;h=2e2bb3f74f5000b1269142d6f9bdf1bcb4075ca4) + +> I can't figure out how to pull from this repository. +>> Sorry! I have fixed the cloneurl file to read `git clone git://webconverger.org/git/ikiwiki` + +I'm unsure how to turn off the test validation by the very old [wdg-html-validator](http://packages.qa.debian.org/w/wdg-html-validator.html). So I have been unable to test my initial patches as I can't build ikiwiki. I would like to know how to edit the rules/Makefile to temporarily disable this. + +> Don't run ¨make test" ... --[[Joey]] +>> I don't quite grok debhelper7 [rules](http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/rules). + +>>> Well, ok :-) `rm t/html.t` or, add an empty `override_dh_auto_test` rule. +>>> --[[Joey]] + +[validator.nu](http://validator.nu/) incidentally is **the** HTML5 validator, however it is almost impossible to sanely introduce as a build dependency because of its insane Java requirements. :( I test locally via [cURL](http://wiki.whatwg.org/wiki/IDE), though Debian packages cannot be built with a network dependency. + +# Notes + +* 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 with iso8601 time +* I suspect the migration to the new semantic elements of HTML5 like article, header & footer to take some time, due to browser support. Though they sure make the template code look much nicer. +* `<br>` and too many `<div>`s usually indicates poor semantics. + > YMMV, but I tend to find that kind of concern counterproductive. + > --[[Joey]] + +* Many of the header `<span>`s should be proper [header elements](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements) + > See [[todo/Option_to_make_title_an_h1__63__]] for why not. --[[Joey]] diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn index e8f87f9c4..3d0c99b83 100644 --- a/doc/bugs/http_proxy_for_openid.mdwn +++ b/doc/bugs/http_proxy_for_openid.mdwn @@ -6,10 +6,42 @@ I have found if I add: newenviron[i++]="HTTPS_PROXY=http://host.domain.com:3128"; -to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured. +to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not hard coded. Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the [[bug_report|ssl_certificates_not_checked_with_openid]] I filed on this separate issue. Unfortunately, HTTP\_PROXY doesn't work for http requests, it looks like that library is different. +--- + +Update 2008-10-26: + +Better solution, one that works for both http and https, and uses config options. It appears to work... + +Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implemented" error, see <http://community.activestate.com/forum-topic/lwp-https-requests-proxy>. Also see [[!debbug 129528]]. + +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. + +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 +@@ -165,6 +165,14 @@ + $ua=LWP::UserAgent->new; + } + ++ if (defined($config{"http_proxy"})) { ++ $ua->proxy(['http'], $config{"http_proxy"}); ++ } ++ ++ if (defined($config{"https_proxy"})) { ++ $ENV{HTTPS_PROXY} = $config{"https_proxy"}; ++ } ++ + # Store the secret in the session. + my $secret=$session->param("openid_secret"); + if (! defined $secret) { + + Brian May diff --git a/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn b/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn index 8cfd42e78..8cda7a70f 100644 --- a/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn +++ b/doc/bugs/images_in_inlined_pages_have_wrong_relative_URL.mdwn @@ -11,3 +11,5 @@ If I then inline that page, the (relative) URL no longer points to the right pla > > However, there is a simple way to avoid both problems: Use WikiLinks > and/or the [[img_directive|ikiwiki/directive/img]]. --[[Joey]] + +[[!tag done]] diff --git a/doc/bugs/img_plugin_should_pass_through_class_attribute.mdwn b/doc/bugs/img_plugin_should_pass_through_class_attribute.mdwn index 2e67d6357..f72ecade2 100644 --- a/doc/bugs/img_plugin_should_pass_through_class_attribute.mdwn +++ b/doc/bugs/img_plugin_should_pass_through_class_attribute.mdwn @@ -26,7 +26,7 @@ And here's a patch to implement it. Will this survive markdown munging? It seems index 7226231..3eb1ae7 100644 --- a/Plugin/img.pm +++ b/Plugin/img.pm - @@ -93,9 +93,15 @@ sub preprocess (@) { #{{{ + @@ -93,9 +93,15 @@ sub preprocess (@) { $imgurl="$config{url}/$imglink"; } @@ -42,7 +42,7 @@ And here's a patch to implement it. Will this survive markdown munging? It seems + $result .= '/></a>'; + + return $result; - } #}}} + } 1 -- diff --git a/doc/bugs/inline_sort-by-title_issues.mdwn b/doc/bugs/inline_sort-by-title_issues.mdwn index 884846b32..ff4555067 100644 --- a/doc/bugs/inline_sort-by-title_issues.mdwn +++ b/doc/bugs/inline_sort-by-title_issues.mdwn @@ -23,7 +23,7 @@ And here is a [[patch]] for this. It makes `sort=title` actually sort on the ti index 9c336e7..99f6de3 100644 --- a/IkiWiki/Plugin/inline.pm +++ b/IkiWiki/Plugin/inline.pm - @@ -185,9 +185,12 @@ sub preprocess_inline (@) { #{{{ + @@ -185,9 +185,12 @@ sub preprocess_inline (@) { } } diff --git a/doc/bugs/inline_sort_order_and_meta_date_value.mdwn b/doc/bugs/inline_sort_order_and_meta_date_value.mdwn new file mode 100644 index 000000000..d4ec8f345 --- /dev/null +++ b/doc/bugs/inline_sort_order_and_meta_date_value.mdwn @@ -0,0 +1,314 @@ +I have a directory containing two files. f1 (<http://alcopop.org/~jon/repro2/src/blog/debgtd.html>) has + + meta date="2008-07-02 14:13:17" + +f2 (<http://alcopop.org/~jon/repro2/src/blog/moving.html>) has + + meta date="2008-07-02 21:04:21" + +They have both been modified recently: + + >>> stat(f1) + (33188, 459250L, 65027L, 1, 1000, 1000, 1686L, 1227967177, 1227966706, 1227966706) + >>> stat(f2) + (33188, 458868L, 65027L, 1, 1000, 1000, 938L, 1227967187, 1227966705, 1227966705) + +Note that f1 is fractionally newer than f2 in terms of ctime and mtime, but f2 is much newer in terms of the meta information. + +Another page includes them both via inline: + + inline pages="blog/*" show=5 + +The resulting page is rendered with f1 above f2, seemingly not using the meta directive information: <http://alcopop.org/~jon/repro2/dest/blog/>. The footer in the inline pages does use the correct time e.g. <em>Posted Wed 02 Jul 2008 14:13:17 BST</em>. + +If I instead include them using creation_year in the pagespec, they are ordered correctly. + +<http://alcopop.org/~jon/repro2/> contains the src used to reproduce this, the precise ikiwiki invocation (inside Makefile) and the results (dest). + +-- [[users/Jon]] + + +> On Ikiwiki 2.53.3 (Debian Lenny), my inlines are also sorted using mtime +> by default -- despite what the [[documentation|/ikiwiki/directive/inline]] +> says -- but setting the supposed default sort order manually produces the +> correct results. For example, the following inline sorts my blog +> entires using their meta date or ctime: +> +> inline pages="blog/*" show="10" sort="age" +> +> I'll try to look at the code this weekend and see if age is really the +> default sort order. +> +> -- [David A. Harding](http://dtrt.org), 2008-12-20 + +Here is the code. As you can see, sort="age" is equivilant to leaving +out the sort option. --[[Joey]] + + if (exists $params{sort} && $params{sort} eq 'title') { + @list=sort { pagetitle(basename($a)) cmp pagetitle(basename($b)) } @list; + } + elsif (exists $params{sort} && $params{sort} eq 'mtime') { + @list=sort { $pagemtime{$b} <=> $pagemtime{$a} } @list; + } + elsif (! exists $params{sort} || $params{sort} eq 'age') { + @list=sort { $pagectime{$b} <=> $pagectime{$a} } @list; + } + else { + return sprintf(gettext("unknown sort type %s"), $params{sort}); + } + +> On further testing, I find that the bug is limited to the first time +> creation time should be used and has nothing to do with setting the sort +> parameter. Revised steps to reproduce: --[David A. Harding](http://dtrt.org), 2008-12-20 +> +> 1. Create pages that sort different by mtime and ctime +> +> 2. inline pages="somepages/*" +> +> 3. ikiwiki --setup setup_file +> +> 4. Pages are output incorrectly in mtime order +> +> 5. ikiwiki --setup setup_file +> +> 6. Pages are output correctly in ctime order +> +> 7. Create new page in somepages/, set its ctime to earlier than another +> page in sompages/ +> +> 8. ikiwiki --setup setup_file +> +> 9. All previously sorted pages output correctly in ctime order but new +> page is output incorrectly at the top as if its mtime was its ctime +> +> 10. ikiwiki --setup setup_file +> +> 11. All pages, including new page, are output correctly in ctime order + +You're confusing ctime and creation time. This is perhaps not suprising, as +ikiwiki uses the term 'ctime' to refer to creation time. However, the unix +ctime value is not the same thing. Unix ctime can change if a file changes +owner, or in some cases, permissions. Unix ctime also always changes +when the file is modified. Ikiwiki wants a first creation date of the file, +and it accomplishes this by recording the initial ctime of a file the first +time it processes it, and *preserving* that creation time forever, ignoring +later ctime changes. + +I suspect that this, coupled with the fact that ikiwiki sorts newest pages +first, explains everything you describe. If not, please send me a shell script +test case I can run, as instructions like "Create pages that sort different by +mtime and ctime" are not ones that I know how to follow (given that touch sets +*both*). --[[Joey]] + +> Sorry. I conflated Unix ctime and ikiwiki's creation time because I +> didn't think the difference was important to this case. I'm a writer, +> and I should have known better -- I appologize. Revised steps to +> reproduce are below; feel free to delete this whole misunderstanding +> to make the bug report more concise. +> +> 1. Create pages in the srcdir that should sort in one order by +> last-modification time and in a diffent order by original creation +> time. For example: +> +> $ echo -e '\[[!meta date="2007-01-01"]]\nNew.' > test/new.mdwn +> $ echo -e '\[[!meta date="2006-01-01"]]\nOld.' > test/old.mdwn +> +> 2. Create a page that includes the files. For example: +> +> +> $ echo '\[[!inline pages="test/*"]]' > sort-test.mdwn +> +> 3. Run ikiwiki. For example `ikiwiki --setup setup_file` +> +> 4. Pages are output incorrectly in modification time order. For example, +> actual partial HTML of the sort-test/index.html from commands used +> above (whitespace-only lines removed; one whitespace-only line +> added): +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/old/">old</a> +> </span> +> <p>Old.</p> +> <span class="pagedate"> +> Posted Sun 01 Jan 2006 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/new/">new</a> +> </span> +> <p>New.</p> +> <span class="pagedate"> +> Posted Mon 01 Jan 2007 12:00:00 AM EST +> </span> +> </div> +> +> 5. Run ikiwiki again with the same command line. For example: `ikiwiki --setup setup_file` +> +> 6. Pages are output correctly in creation time order. For example, +> actual partial HTML of the sort-test/index.html from commands used +> above (whitespace-only lines removed; one whitespace-only line +> added): +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/new/">new</a> +> </span> +> <p>New.</p> +> <span class="pagedate"> +> Posted Mon 01 Jan 2007 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/old/">old</a> +> </span> +> <p>Old.</p> +> <span class="pagedate"> +> Posted Sun 01 Jan 2006 12:00:00 AM EST +> </span> +> </div> +> +> 7. Create a new page with the current Unix mtime and Unix ctime, but a +> !meta date before the most recent creation date of another page. +> For example: +> +> $ echo -e '\[[!meta date="2005-01-01"]]\nOlder.' > test/older.mdwn +> +> 8. Run ikiwiki again with the same command line. For example: `ikiwiki --setup setup_file` +> +> 9. All previously sorted pages output correctly in order of their +> creation time, but the new page is output incorrectly at the top as +> if its modification time was its creation time. For example, +> actual partial HTML of the sort-test/index.html from commands used +> above (whitespace-only lines removed; two whitespace-only +> lines added): +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/older/">older</a> +> </span> +> <p>Older.</p> +> <span class="pagedate"> +> Posted Sat 01 Jan 2005 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/new/">new</a> +> </span> +> <p>New.</p> +> <span class="pagedate"> +> Posted Mon 01 Jan 2007 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/old/">old</a> +> </span> +> <p>Old.</p> +> <span class="pagedate"> +> Posted Sun 01 Jan 2006 12:00:00 AM EST +> </span> +> </div> +> +> 10. Run ikiwiki again with the same command line. For example: `ikiwiki --setup setup_file` +> +> 11. All pages, including new page, are output correctly in creation time +> order. For example, actual partial HTML of the sort-test/index.html +> from commands used above (whitespace-only lines removed; two +> whitespace-only lines added): +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/new/">new</a> +> </span> +> <p>New.</p> +> <span class="pagedate"> +> Posted Mon 01 Jan 2007 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/old/">old</a> +> </span> +> <p>Old.</p> +> <span class="pagedate"> +> Posted Sun 01 Jan 2006 12:00:00 AM EST +> </span> +> </div> +> +> <div class="inlinepage"> +> <span class="header"> +> <a href="./../test/older/">older</a> +> </span> +> <p>Older.</p> +> <span class="pagedate"> +> Posted Sat 01 Jan 2005 12:00:00 AM EST +> </span> +> </div> +> +> File status after all the above actions: +> +> $ stat test/* +> File: `test/new.mdwn' +> Size: 33 Blocks: 8 IO Block: 4096 regular file +> Device: ca20h/51744d Inode: 684160 Links: 1 +> Access: (0644/-rw-r--r--) Uid: ( 1000/ harding) Gid: ( 1000/ harding) +> Access: 2008-12-20 21:48:32.000000000 -0500 +> Modify: 2008-12-20 21:27:03.000000000 -0500 +> Change: 2008-12-20 21:27:03.000000000 -0500 +> File: `test/older.mdwn' +> Size: 35 Blocks: 8 IO Block: 4096 regular file +> Device: ca20h/51744d Inode: 684407 Links: 1 +> Access: (0644/-rw-r--r--) Uid: ( 1000/ harding) Gid: ( 1000/ harding) +> Access: 2008-12-20 21:48:32.000000000 -0500 +> Modify: 2008-12-20 21:42:10.000000000 -0500 +> Change: 2008-12-20 21:42:10.000000000 -0500 +> File: `test/old.mdwn' +> Size: 33 Blocks: 8 IO Block: 4096 regular file +> Device: ca20h/51744d Inode: 684161 Links: 1 +> Access: (0644/-rw-r--r--) Uid: ( 1000/ harding) Gid: ( 1000/ harding) +> Access: 2008-12-20 21:48:32.000000000 -0500 +> Modify: 2008-12-20 21:27:09.000000000 -0500 +> Change: 2008-12-20 21:27:09.000000000 -0500 +> +> My ikiwiki configuration file (being used to port a blog from pyblosxom +> to ikiwiki): +> +> harding@mail:~$ sed 's/#.*//; /^[ ]*$/d' .ikiwiki/gnuisance.setup +> use IkiWiki::Setup::Standard { +> wikiname => "HardingBlog", +> adminemail => 'dave@dtrt.org', +> srcdir => "/srv/backup/git/gnuisance.net", +> destdir => "/srv/test.dtrt.org", +> url => "http://srv.dtrt.org", +> wrappers => [ +> ], +> atom => 1, +> syslog => 0, +> prefix_directives => 1, +> add_plugins => [qw{goodstuff tag}], +> disable_plugins => [qw{passwordauth}], +> tagbase => "tag", +> } +> +> --[David A. Harding](http://dtrt.org/), 2008-12-20 + +Thank you for a textbook excellent reproduction recipe. + +What appears to be going on here is that meta directives are not processed +until the leaf pages are rendered, and thus the ctime setting is not +available at the time that they are inlined, and the newer unix ctime is +used. On the second build, the meta data has already been recorded. + +This can probably be avoided by processing meta date at scan time. + +Verified, fix works. [[done]] +--[[Joey]] diff --git a/doc/bugs/links_misparsed_in_CSV_files.mdwn b/doc/bugs/links_misparsed_in_CSV_files.mdwn new file mode 100644 index 000000000..27d2b7b1e --- /dev/null +++ b/doc/bugs/links_misparsed_in_CSV_files.mdwn @@ -0,0 +1,27 @@ +If a link inside a CSV file contains two or more underscores (\_), then it will get mis-parsed by the table plugin. + +e.g. \[[single\_track\_lines]] becomes "em>lines". + +Links with only one underscore are OK. + +Update 2008-11-24: The problem only occurs if the CSV data is in an external file. If I load it using data="""...""" then it works fine. + +The problem appears to be the call to htmlize inside genrow. If the data is inline, then wikilinks get expanded before they get here, and are OK. If the data is from an external file, the wikilinks aren't expanded, and htmlize will expand \[[single\_track\_lines]] into \[[single<em>track</em>lines]]. + +Oh, wait, I see the problem. IkiWiki::linkify is only called if the external file doesn't exist. If I remove this check and always call IkiWiki::linkify, then the problem is solved. + +(this is inside /usr/share/perl5/IkiWiki/Plugin/table.pm). + +> To reproduce this bug, I had to install the old, broken markdown 1.0, +> instead of the now-default Text::Markdown. +> +> Why is linkify not called for external files? Well, I checked the +> history, and it's probably best to say "for historical reasons that no +> longer apply". So, changed as you suggest. [[done]] --[[Joey]] + +I am rather confused what this check does, and the fact the comments are very different for CSV and DSV when the code is the same doesn't seem to help. + +> The code is not the same; two operations are run in different orders for +> CSV and DSV, as the comments note. --[[Joey]] + +-- Brian May diff --git a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn index c835d9f98..b8023ce87 100644 --- a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn +++ b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn @@ -1,4 +1,4 @@ -[[plugins/lockedit]] adds the form fields for a [[pagespec]] to preferences. This pagespec should be supplied "raw"; i.e., without quotes around it. Inexperienced users (such as [[myself|jondowland]]) may provide an invalid pagespec, such as one with quotes on it. This will be merrily accepted by the form, but will cause no locking to take place. +[[plugins/lockedit]] adds the form fields for a [[pagespec]] to preferences. This pagespec should be supplied "raw"; i.e., without quotes around it. Inexperienced users (such as [[myself|users/jon]]) may provide an invalid pagespec, such as one with quotes on it. This will be merrily accepted by the form, but will cause no locking to take place. Perhaps some validation should be performed on the pagespec and the form-submission return include "warning: this pagespec is invalid" or "warning: this pagespec does not match any existing pages" or similar. @@ -15,3 +15,7 @@ Perhaps some validation should be performed on the pagespec and the form-submiss > There are small classes of invalid pagespecs. For example, `(foo or bar` > is invalid due to having unbalanced parens, while `foo or and bar` > has invalid syntax. It's possible to detect these, I guess ... --[[Joey]] + +>> Having moved it to the .setup file makes things more obvious I think. +>> Anyway I consider this [[done]], please de-done this if you disagree. +>> --[[Jon]] diff --git a/doc/bugs/login_page_should_note_cookie_requirement.mdwn b/doc/bugs/login_page_should_note_cookie_requirement.mdwn new file mode 100644 index 000000000..96686053c --- /dev/null +++ b/doc/bugs/login_page_should_note_cookie_requirement.mdwn @@ -0,0 +1,33 @@ +At the moment, you go through the login shuffle and then are told that cookies are needed, so you lose all your data and login again. It would be much slicker to note by the edit link, or at least on the login page, that cookies are required. + +> Hmm, it seems to me to be fairly obvious, since the vast majority of +> websites that have a login require cookies. Such warnings used to be +> common, but few sites bother with them anymore. --[[Joey]] + +>> Very few websites break without cookies. Even fewer lose data. +>> Can ikiwiki avoid being below average by default? --[MJR](http://mjr.towers.org.uk) + +>>> Can we avoid engaging in hyperbole? (Hint: Your browser probably has a +>>> back button. Hint 2: A username/password does not count as "lost data". +>>> Hint 3: Now we're arguing, which is pointless.) --[[Joey]] + +Even better would be to only display the cookie note as a warning if the login page doesn't receive a session cookie. + +> I considered doing this before, but it would require running the cgi once +> to attempt to set the cookie and then redirecting to the cgi a second +> time to check if it took, which is both complicated and probably would +> look bad. + +>> Might this be possible client-side with javascript? A quick google suggests it is possible: +>> <http://www.javascriptkit.com/javatutors/cookiedetect.shtml>. MJR, want to try adding +>> that? -- [[Will]] + +Best of all would be to use URL-based or hidden-field-based session tokens if cookies are not permitted. + +> This is not very doable since most of the pages the user browses are +> static pages in a static location. + +>> The pages that lose data without cookies (the edit pages, primarily) +>> 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. diff --git a/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn b/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn index 5c04dce03..6fccc5c86 100644 --- a/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn +++ b/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn @@ -8,7 +8,7 @@ compare: It seems putting a '+' in there throws it. Maybe it's a markdown bug, or maybe the obfuscation markdown applies to email-links is being caught by the HTML sanitizer. - -- [[JonDowland]] + -- [[users/Jon]] > It's a markdown bug. For some reason, markdown doesn't recognize the email with a '+' as an email: > diff --git a/doc/bugs/mercurial_fail_to_add.mdwn b/doc/bugs/mercurial_fail_to_add.mdwn index dab40d684..3bbf4e5fd 100644 --- a/doc/bugs/mercurial_fail_to_add.mdwn +++ b/doc/bugs/mercurial_fail_to_add.mdwn @@ -6,7 +6,7 @@ Here is a patch that's seems to work, although I'm not quite sure what's wrong w --- mercurial.pm 2007-03-24 16:14:35.000000000 +0100 +++ /home/hbernard/mercurial.pm 2007-04-19 19:05:47.000000000 +0200 @@ -95,7 +95,7 @@ - sub rcs_add ($) { # {{{ + sub rcs_add ($) { my ($file) = @_; - my @cmdline = ("hg", "-q", "-R", "$config{srcdir}", "add", "$file"); diff --git a/doc/bugs/messed_up_repository.mdwn b/doc/bugs/messed_up_repository.mdwn new file mode 100644 index 000000000..e245b84a8 --- /dev/null +++ b/doc/bugs/messed_up_repository.mdwn @@ -0,0 +1,21 @@ +I messed up my local clone of my repository. + +It appears that there is a special clone, which contains .ikiwiki, local.css, recentchanges, and the like. + +How can I create a new version of this clone? + +> No, there's the srcdir, which ikiwiki populates with some of those files +> when run. Notably the .ikiwiki directory and all its contents, and the +> recentchanges directory and its contents. But not local.css. +> +> If you've lost .ikiwiki and it contained user registration info +> (passwords etc), you've lost that info. Everything else can be +> regenerated by running `ikiwiki -setup your.setup` +> +> If you still have .ikiwiki, but the git clone is messed up somehow, you +> can just make a new clone and move .ikiwiki into it before running +> ikiwiki. --[[Joey]] + +> > Great, that worked. Thanks Joey! + +[[!tag done]] diff --git a/doc/bugs/methodResponse_in_add__95__plugins.mdwn b/doc/bugs/methodResponse_in_add__95__plugins.mdwn index 8a88f4eda..c82b532db 100644 --- a/doc/bugs/methodResponse_in_add__95__plugins.mdwn +++ b/doc/bugs/methodResponse_in_add__95__plugins.mdwn @@ -26,7 +26,7 @@ index e476521..d43abd4 100644 --- a/IkiWiki.pm +++ b/IkiWiki.pm - @@ -471,7 +471,11 @@ sub loadplugins () { #{{{ + @@ -471,7 +471,11 @@ sub loadplugins () { unshift @INC, possibly_foolish_untaint($config{libdir}); } diff --git a/doc/bugs/multiple_pages_with_same_name.mdwn b/doc/bugs/multiple_pages_with_same_name.mdwn index 5ddfb1f6b..20c38c062 100644 --- a/doc/bugs/multiple_pages_with_same_name.mdwn +++ b/doc/bugs/multiple_pages_with_same_name.mdwn @@ -28,14 +28,14 @@ Suggestions welcome. index 4e4da11..853f905 100644 --- a/IkiWiki.pm +++ b/IkiWiki.pm - @@ -618,7 +618,7 @@ sub pagename ($) { #{{{ + @@ -618,7 +618,7 @@ sub pagename ($) { my $type=pagetype($file); my $page=$file; - $page=~s/\Q.$type\E*$// if defined $type; + $page=~s/\Q.$type\E*$// if defined $type && !$hooks{htmlize}{$type}{leavesuffix}; return $page; - } #}}} + } diff --git a/t/pagename.t b/t/pagename.t index 96e6a87..58811b9 100755 @@ -61,7 +61,7 @@ I wonder if this patch will also be useful: index 752d176..3f1b67b 100644 --- a/IkiWiki/Render.pm +++ b/IkiWiki/Render.pm - @@ -279,7 +279,11 @@ sub refresh () { #{{{ + @@ -279,7 +279,11 @@ sub refresh () { else { $f=~s/^\Q$config{srcdir}\E\/?//; push @files, $f; diff --git a/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn b/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn new file mode 100644 index 000000000..132d23463 --- /dev/null +++ b/doc/bugs/output_of_successful_rename_should_list_the_full_path_to_affected_pages.mdwn @@ -0,0 +1,14 @@ +I've just renamed a page and received the following as a result: + +<p> +<b>Successfully renamed users/jondowland.mdwn to users/jon.mdwn.</b> +</p> +<p> + +The following pages have been automatically modified to update their links to users/jon.mdwn: +<ul> +<li><a href="./../../tips/convert_mediawiki_to_ikiwiki/discussion/">discussion</a></li><li><a href="./../../tips/untrusted_git_push/discussion/">discussion</a></li></ul>... + +In this situation I think the link to pages should be expanded to show the entire path, since there is quite likely to be a lot of things like "discussion". -- [[users/Jon]] + +[[done]] diff --git a/doc/bugs/pagespec_parsing_chokes_on_function__40____41__.mdwn b/doc/bugs/pagespec_parsing_chokes_on_function__40____41__.mdwn index a2eba694c..78fed0e5d 100644 --- a/doc/bugs/pagespec_parsing_chokes_on_function__40____41__.mdwn +++ b/doc/bugs/pagespec_parsing_chokes_on_function__40____41__.mdwn @@ -54,7 +54,7 @@ case the user is given to rebuilding the wiki by hand. --Ethan + } return IkiWiki::FailReason->new("syntax error") if $@; return $ret; - } #}}} + } </pre> > Thanks, [[done]] --[[Joey]] 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 a30ab0fa3..4a83f9ec8 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -1,3 +1,233 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text. --[[madduck]] + +---- + +It is possible to set a Page-Title in the meta-plugin, but that one isn't +reused in parentlinks. This [[patch]] may fix it. + +<ul> +<li> I give pagetitle the full path to a page. +<li> I redefine the 'pagetitle'-sub to deal with it. +<li> to maintain compatibility for IkiWikis without the meta-plugin, i added a 'basename' to the Original-pagetitle. +</ul> + +<pre> +diff -c /usr/share/perl5/IkiWiki/Render.pm.distrib /usr/share/perl5/IkiWiki/Render.pm +*** /usr/share/perl5/IkiWiki/Render.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Render.pm Tue Aug 26 23:29:32 2008 +*************** +*** 102,108 **** + $template->param( + title => $page eq 'index' + ? $config{wikiname} +! : pagetitle(basename($page)), + wikiname => $config{wikiname}, + content => $content, + backlinks => $backlinks, +--- 102,108 ---- + $template->param( + title => $page eq 'index' + ? $config{wikiname} +! : pagetitle($page), + wikiname => $config{wikiname}, + content => $content, + backlinks => $backlinks, + +diff -c /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm.distrib /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm +*** /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm Tue Aug 26 23:19:43 2008 +*************** +*** 44,50 **** + "height_$height" => 1, + }; + $path.="/".$dir; +! $title=IkiWiki::pagetitle($dir); + $i++; + } + return @ret; +--- 44,50 ---- + "height_$height" => 1, + }; + $path.="/".$dir; +! $title=IkiWiki::pagetitle($path); + $i++; + } + return @ret; + +diff -c /usr/share/perl5/IkiWiki.pm.distrib /usr/share/perl5/IkiWiki.pm +*** /usr/share/perl5/IkiWiki.pm.distrib Wed Aug 6 07:48:34 2008 +--- /usr/share/perl5/IkiWiki.pm Tue Aug 26 23:47:30 2008 +*************** +*** 792,797 **** +--- 792,799 ---- + my $page=shift; + my $unescaped=shift; + ++ $page=basename($page); ++ + if ($unescaped) { + $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : chr($2)/eg; + } + +diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki/Plugin/meta.pm +*** /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Plugin/meta.pm Tue Aug 26 23:30:58 2008 +*************** +*** 3,8 **** +--- 3,9 ---- + package IkiWiki::Plugin::meta; + + use warnings; ++ no warnings 'redefine'; + use strict; + use IkiWiki 2.00; + +*************** +*** 289,294 **** +--- 290,319 ---- + } + } + ++ sub IkiWiki::pagetitle ($;$) { ++ my $page=shift; ++ my $unescaped=shift; ++ ++ if ($page =~ m#/#) { ++ $page =~ s#^/##; ++ $page =~ s#/index$##; ++ if ($pagestate{"$page/index"}{meta}{title}) { ++ $page = $pagestate{"$page/index"}{meta}{title}; ++ } else { ++ $page = IkiWiki::basename($page); ++ } ++ } ++ ++ if ($unescaped) { ++ $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : chr($2)/eg; ++ } ++ else { ++ $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : "&#$2;"/eg; ++ } ++ ++ return $page; ++ } ++ + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + +</pre> + +---- + +> A few quick notes about it: + +> - Using <code>inline</code> would avoid the redefinition + code duplication. +> - A few plugins would need to be upgraded. +> - It may be necessary to adapt the testsuite in `t/pagetitle.t`, as well. +> +> --[[intrigeri]] +> +>> It was actually more complicated than expected. A working prototype is +>> now in my `meta` branch, see my userpage for the up-to-date url. +>> Thus tagging [[patch]]. --[[intrigeri]] +>> +>>> Joey, please consider merging my `meta` branch. --[[intrigeri]] + +So, looking at your meta branch: --[[Joey]] + +* Inter-page dependencies. If page A links to page B, and page B currently + 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. + 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 + handler that can detect when B's title has changed and only rebuild pages + that link to B in that case. +* Looks like some plugins that use `pagetitle` to format it for display + were not changed to use `nicepagetitle` (for example, rename). + But most of those callers intend to display the page name + as a title, but including the parent directories in the path. (Ie, + "renaming foo/page title to bar/page title" -- + you want to know it's moved from foo to bar.) `nicepagetitle` does not + allow doing that since it always takes the `basename`. +* I don't like the name `nicepagetitle`. It's not very descriptive, is it? + And it seems very confusing to choose whether to use the "nice" or original + version. My hope is that adding a second function is unnecessary. + As I understand it, you added a new function for two reasons: + 1) It needs the full page name, not basename. + 2) `titlepage(pagetitle($page))` reversability. + + 1) If you look at all the callers + Of `pagetitle` most of them pass a complete page name, not just the + basename. In most cases `pagetitle` is used to display the full name + of the page, including any subdirectory it's in. So why not just make + it consitently be given the full name of the page, with another argument + specifying if we want to get back just the base name. + + 2) I can't find any code that actually uses the reversability like that. + The value passed to `titlepage` always comes from some external + source. Unless I missed one. +* The use of `File::Spec->rel2abs` is a bit scary. +* Does it really make sense to call `pagetitle` on the meta title + in meta's `nicepagetitle`? What if the meta title is something like + "foo_bar" -- that would be changed to "foo bar". +* parentlinks is changed to use `nicepagetitle(bestlink($page, $path))`. + Won't `bestlink` return "" if the parent page in question does not exist? +* `backlinks()` is changed to add an additional `title` field + to the hash returned, but AFAICS this is not used in the template. +* Shouldn't `Render.pm` use nicepagetitle when getting the title for the + page template? Then meta would not need to override the title in the + `pagetemplate` hook. (Although this would eliminate handling of + `title_overridden` -- but that is little used and would not catch + all the other ways titles can be overridden with this patch anyway.) + +> I'm not a reviewer or anything, but can I chime in on changes to pagetitle? +> I don't think having meta-titles in wikilinks and the parentlinks path by +> default is necessarily a good thing. I don't consider the meta-title of a page +> as used in `<title>` to be the same thing as the short title you +> want in those contexts - IMO, the meta-title is the "formal" title of the page, +> enough to identify it with no other context, and frequently too long to be used +> as a link title or a parentlink, whereas the parentlinks title in particular +> should be some abbreviated form that's enough to identify it in context. +> [tbm](http://www.cyrius.com/) expressed a similar opinion when I was discussing +> ikiwiki with him at the weekend. +> +> It's a matter of taste whether wikilinks are "like a parentlink" or "like a +> `<title>`"; I could be persuaded either way on that one. +> +> An example from my site: [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/) +> is the parent of [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/wifi/) +> with a title too long to use in the latter's parentlinks; I think the titles of +> both those pages are too long to use as wikilink text too. Similarly, tbm's page +> about [Debian on Orion devices from Buffalo](http://www.cyrius.com/debian/orion/buffalo/) +> can simply be called "Buffalo" in context. +> +> Having a `\[[!meta abbrev="..."]]` that took precedence over title +> in parentlinks and possibly wikilinks might be a good way to fix this? Or if your +> preference goes the other way, perhaps a `\[[!meta longtitle=""]]` could take +> precedence when generating the `<title>` and the title that comes after the +> parentlinks. --[[smcv]] + +>> I think you've convinced me. (I had always had some doubt in my mind as +>> to whether using titles in all these other places would make sense.) +>> +>> Instead of meta abbrev, you could have a meta pagename that +>> overrides the page name displayed everywhere (in turn overridden by +>> meta title iff the page's title is being displayed). But is this complexity +>> needed? We have meta redir, so if you want to change the name of a page, +>> you can just rename it, and put in a stub redirection page so links +>> still work. +>> +>> This leaves the [[plugins/contrib/po]] plugin, which really does need +>> a way to change the displayed page name everywhere, and at least a +>> subset of the changes in the meta branch are needed to support that. +>> +>> (This would also get around my concern about inter-page dependency +>> handling, since po contains a workaround for that, and it's probably +>> acceptable to use potentially slow methods to handle this case.) +>> --[[Joey]] diff --git a/doc/bugs/prune_causing_taint_mode_failures.mdwn b/doc/bugs/prune_causing_taint_mode_failures.mdwn index 1876d9129..5fc1d8b75 100644 --- a/doc/bugs/prune_causing_taint_mode_failures.mdwn +++ b/doc/bugs/prune_causing_taint_mode_failures.mdwn @@ -11,7 +11,7 @@ I've no idea what's happening (hey, I'm a C programmer), but I've hacked prune() <pre> use Scalar::Util qw(tainted); -sub prune ($) { #{{{ +sub prune ($) { my $file=shift; unlink($file); @@ -25,7 +25,7 @@ sub prune ($) { #{{{ $dir = $1; } } -} #}}} +} </pre> > Old versions of perl are known to have bugs with taint checking. diff --git a/doc/bugs/quieten_mercurial.mdwn b/doc/bugs/quieten_mercurial.mdwn index 26f833e5f..3fd75ea1b 100644 --- a/doc/bugs/quieten_mercurial.mdwn +++ b/doc/bugs/quieten_mercurial.mdwn @@ -6,7 +6,7 @@ messages which are then taken for CGI output, causing errors and general trouble @@ -55,7 +55,7 @@ } - sub rcs_update () { #{{{ + sub rcs_update () { - my @cmdline = ("hg", "-R", "$config{srcdir}", "update"); + my @cmdline = ("hg", "-q", "-R", "$config{srcdir}", "update"); if (system(@cmdline) != 0) { @@ -22,7 +22,7 @@ messages which are then taken for CGI output, causing errors and general trouble if (system(@cmdline) != 0) { warn "'@cmdline' failed: $!"; @@ -92,7 +92,7 @@ - sub rcs_add ($) { # {{{ + sub rcs_add ($) { my ($file) = @_; - my @cmdline = ("hg", "-R", "$config{srcdir}", "add", "$file"); diff --git a/doc/bugs/recentchanges_feed_links.mdwn b/doc/bugs/recentchanges_feed_links.mdwn index 14f1c26ba..ef0f9d1c4 100644 --- a/doc/bugs/recentchanges_feed_links.mdwn +++ b/doc/bugs/recentchanges_feed_links.mdwn @@ -92,3 +92,16 @@ to turn on? --Chapman Flack >>>>> required to compare `<id>`s as opaque strings. >>>>> >>>>> --[[smcv]] + +>>>>>> Here's my attempt at a [[patch]] for anchor-based change permalinks: +>>>>>> <http://pastie.org/295016>. +>>>>>> --[[JasonBlevins]], 2008-10-17 + +[[JasonBlevins]] nailed it, [[done]] --[[Joey]] + +> Thanks for applying the patch (and improving it). There's still one small issue: +> the old opening div tag still needs to be removed (it's hard to see the removed line +> with the pastie color scheme). +> --[[JasonBlevins]], 2008-10-18 + +>> Thanks, missed that when I had to hand-apply the patch. --[[Joey]] diff --git a/doc/bugs/relative_date_weird_results.mdwn b/doc/bugs/relative_date_weird_results.mdwn new file mode 100644 index 000000000..9f35e47f7 --- /dev/null +++ b/doc/bugs/relative_date_weird_results.mdwn @@ -0,0 +1,4 @@ +I just submitted a new bug, and... after clicking "save", my brand new bug page displays, at the bottom: "Last edited 6 hours and 3 minutes ago". Timezone issue, I guess? (Hint: I'm in France) -- [[intrigeri]] + +> Yep, it wasn't including a timezone in the machine parseable time. +> [[done]] --[[Joey]] diff --git a/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn new file mode 100644 index 000000000..b4e2a1501 --- /dev/null +++ b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn @@ -0,0 +1,20 @@ +Hi! + +How about to replace sparkline-php from Suggests by a better alternative? + +I would like to file a RM bug to get it out of archive. Do you have a better alternative for it? PHP has a lot of them.. + +Thanks + +> sparline-php is orphaned *in Debian*. Upstream, is has seen activity as +> recently as 11 months ago. +> +> I don't know of a better alternative. I looked at the perl sparkline +> stuff in CPAN and is was bad enough that the pain of using php from this +> perl program was a better alternative. +> +> Anyway, it works great; maintaining the sparkline-php package in Debian +> would certianly be much less work than finding some alternative and +> 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]] diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn index 8c7d8134d..9d433e24e 100644 --- a/doc/bugs/rst_tweak.mdwn +++ b/doc/bugs/rst_tweak.mdwn @@ -27,3 +27,17 @@ Does the Perl version of this plugin still exist? There appears to be no "rst.p > No, only the python version exists. It does have `raw_enabled` set. > --[[Joey]] + +I am sorry, but I am confused. Does this mean that I can use Ikiwiki +features that translate to HTML in rst files? For example, when I use a +\[[pagename]]-style link in a rst file, the page generated by Ikiwiki's rst +plugin says <a href="./../pagename/">pagename</a> as text. The link +is expanded correctly, but the result isn't interpreted as HTML. Is that +what is supposed to happen? --Peter + +> `raw_enabled` allows you to use the +> [raw directive](http://docutils.sourceforge.net/docs/ref/rst/directives.html), +> but this is not used by ikiwiki for wikilinks or anything else. +> 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]] diff --git a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn index 0a2b1efea..dace2ca19 100644 --- a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn +++ b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn @@ -2,7 +2,7 @@ It seems like gettext only searches for locale information in /usr/share/locale, --- a/IkiWiki.pm +++ b/IkiWiki.pm - @@ -1057,6 +1057,7 @@ sub gettext { #{{{ + @@ -1057,6 +1057,7 @@ sub gettext { $gettext_obj=undef; return shift; } diff --git a/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn b/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn new file mode 100644 index 000000000..5cc669106 --- /dev/null +++ b/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn @@ -0,0 +1,33 @@ +On my initial ikiwiki -setup auto.setup, I get the following error: + + shortcut plugin will not work without shortcuts.mdwn + /home/turian/utils/etc/ikiwiki/auto.setup: ikiwiki --refresh --setup /home/turian/iki.setup failed at IkiWiki/Setup/Automator.pm line 105. + + +This is using the latest git pull of ikiwiki. +I am not sure why it is not finding shortcuts.mdwn. -- [[JosephTurian]] + +> The error, and the weird paths suggest to me that you +> have installed ikiwiki in a strange way, and it is failing +> to find its basewiki underlay. The `$installdir` is +> hardcoded into IkiWiki.pm at build time, based on the PREFIX +> setting (see README). +> +> If that's not set right, you'll have other problems than just this one, +> so I suggest you check how you installed ikiwiki. +> +> Anyway, I've made the shortcut plugin only warn about this.. +> --[[Joey]] + +> > I have +> > $installdir="/home/turian/utils/" +> > and the underlay dir is set to: +> > "$installdir/share/ikiwiki/basewiki", +> > which does contain shortcuts.mdwn. So I am not sure why it is not finding it. +> > I am grappling with installing ikiwiki in a user account, and would like to get the directories set up correctly. +> > How can I debug this issue further? + +>>>> Why don't you strace it and look at where it's looking for +>>>> shortcuts.mdwn. --[[Joey]] + +>>>>>> Hmm, so change the PERL5LIB seemed to fix this. [[Done]]. diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn index 2dc74a984..04ece0ae8 100644 --- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -65,4 +65,21 @@ significantly harder than the network based attacks." With regards to implementation, I am surprised that the libraries don't seem to do this checking, already, and by default. Unfortunately, I am not sure how to test -this adequately, see <http://bugs.debian.org/466055>. -- Brian May +this adequately, see [[!debbug 466055]]. -- Brian May + +--- + +I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick +is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to +enable this checking. + +I think the trick is to set one of the the following environment variables before retrieving +the data: + +$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/"; +$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem"; + +Unfortunately I get weird results if the certificate verification fails, see [[!debbug 503440]]. +It still seems to work though, regardless. + +-- Brian May diff --git a/doc/bugs/stray___60____47__p__62___tags.mdwn b/doc/bugs/stray___60____47__p__62___tags.mdwn new file mode 100644 index 000000000..6e508ffda --- /dev/null +++ b/doc/bugs/stray___60____47__p__62___tags.mdwn @@ -0,0 +1,15 @@ +When using the [[plugins/htmltidy]] plugin (and possibly in other circumstances), ikiwiki sometimes creates more `</p>` tags than `<p>` tags, causing unbalanced markup. I've previously noticed unbalanced tags when a `\[[!map]]` matches no pages. This is part of the reason I developed [[plugins/htmlbalance]]. + +This is particularly noticeable if htmltidy is enabled when building the docwiki: on the 'contrib' plugin pages, the title becomes `foo </p> (third-party plugin)` (with the angle-brackets escaped - it seems the text gets sanitized but is then escaped anyway). + +I believe that this snippet in `IkiWiki.pm` might be the reason for the imbalance: + + if ($oneline) { + # hack to get rid of enclosing junk added by markdown + # and other htmlizers + $content=~s/^<p>//i; + $content=~s/<\/p>$//i; + chomp $content; + } + +The fact that HTML in a `\[[!meta title]]` is added but then escaped might indicate that some other bug is involved. diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn new file mode 100644 index 000000000..f78d50c3c --- /dev/null +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -0,0 +1,10 @@ +I have several complaints that users cannot contribute to my ikiwiki instances since they only have OpenID logins that support OpenID2. E.g. Yahoo!'s OpenID only supports 2.0+ + +This is not the fault of ikiwiki, though the problem lies within the [perl openid consumer](http://packages.qa.debian.org/libn/libnet-openid-consumer-perl.html) in Debian which is a 1.x implementation AFAIK. + +I've contacted JanRain who have pointed me to: + +* [OpenID4Perl](http://code.sxip.com/openid4perl/) +* Some [work](http://code.sixapart.com/svn/openid/trunk/perl/) by David Recordon + +However both Perl OpenID 2.x implementations have not been released and are incomplete implementations. :( diff --git a/doc/bugs/table_external_file_links.mdwn b/doc/bugs/table_external_file_links.mdwn new file mode 100644 index 000000000..7b35383c5 --- /dev/null +++ b/doc/bugs/table_external_file_links.mdwn @@ -0,0 +1,9 @@ +If wikilinks are put in an external table file, those links are not seen at +scan time, and so ikiwiki does not know to update the page containing the +table when the pages the links point to change (are added, removed, etc). + +There seem only two solutions to that bug -- either really make wikilinks +in an external table file not work (probably by escaping them), +or run the preprocess code also in scan (expensive!). --[[Joey]] + +[[done]] diff --git a/doc/bugs/tags__44___backlinks_and_3.x.mdwn b/doc/bugs/tags__44___backlinks_and_3.x.mdwn new file mode 100644 index 000000000..4fe9a4723 --- /dev/null +++ b/doc/bugs/tags__44___backlinks_and_3.x.mdwn @@ -0,0 +1,34 @@ +I think there might be an issue in the backlinks calculation in ikiwiki 3.04. + +I've just migrated to 3.04. In doing so, the following pagespec + +> "log/* and !link(tag/aggregation) and !link(tag/draft) and !*/Discussion" + +...started matching pages which contained + +> \[\[!template draft\]\] + +The page templates/draft.mdwn contains (amongst some markup) + +> \[\[!tag draft \]\] + +Prior to migration, the pagespec definitely took effect post-transclusion. + +An example: <http://jmtd.net/log/too_much_debconf_a_bad_thing/> contains the +template inclusion, which can be seen to have worked due to markup at the +bottom of the page. It even includes a "Tags: draft" link at the bottom. + +Strangely, <http://jmtd.net/tag/draft/> does not contain backlinks to pages +which are tagged using the procedure above. + +After the first rebuild, it's broken, after a subsequent refresh, it is fixed. +I've reproduced this twice (but assumed I'd done something wrong the first +time, so went ahead and migrated live, spamming planet debian in the process +:(). I will try and put together a testcase. -- [[users/Jon]], 2009/02/17 + +> Looks like the same problem as +> [[cannot_reliably_use_meta_in_template]]. AFAIK, this has never worked +> reliably, although the linked page has a simple, though potentially +> expensive fix. --[[Joey]] + +> fix made, [[done]] --[[Joey]] diff --git a/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn b/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn index ac895896a..db3917d21 100644 --- a/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn +++ b/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn @@ -25,12 +25,12 @@ After some digging I found that HTML::Template is being required after the new s filter => sub { my $text_ref = shift; @@ -857,6 +856,7 @@ - } #}}} + } - sub template ($;@) { #{{{ + sub template ($;@) { + require HTML::Template; HTML::Template->new(template_params(@_)); - } #}}} + } **That** gave me: diff --git a/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn b/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn index 7ec1edc4e..bdd07210e 100644 --- a/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn +++ b/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn @@ -9,6 +9,6 @@ The first two complaints happen if textile is not loaded, the third fatal one ha 0x92 is "single quote" in the evil windows default codepage. It would be nice to handle this gracefully and not abort ikiwiki at this point, or alternatively, die fatally but mention which input page caused the error. -Interestingly enough, in my case, the input file has several other bad windows characters (0xFC, u-umlaut) which have not caused ikiwiki to abort. ikiwiki version 2.50. -- [[JonDowland]] +Interestingly enough, in my case, the input file has several other bad windows characters (0xFC, u-umlaut) which have not caused ikiwiki to abort. ikiwiki version 2.50. -- [[users/Jon]] > Fixed in git. [[done]] --[[Joey]] diff --git a/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn b/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn new file mode 100644 index 000000000..22224483e --- /dev/null +++ b/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn @@ -0,0 +1,19 @@ +When applying my usual copyright and licensing header to a [[plugins/txt]] +page, garbled output is created. + +Here is the header: + + \[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008 Free + Software Foundation, Inc."]] + + \[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable + id="license" text="Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free Documentation License, + Version 1.2 or any later version published by the Free Software Foundation; + with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. + A copy of the license is included in the section entitled + [[GNU_Free_Documentation_License|/fdl]]."]]"""]] + +--[[tschwinge]] + +> [[done]], made it less zealous about encoding html entities. --[[Joey]] diff --git a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn new file mode 100644 index 000000000..472597c46 --- /dev/null +++ b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn @@ -0,0 +1,20 @@ +I spent hours trying to understand why my wiki suddenly refused me to log in (using passwordauth). +The failure message was always: `login failed, perhaps you need to turn on cookies?` + +Inspecting the cookie information (thanks to Iceweasel's webdeveloper add-on), I realized there were some weird-looking encoded chars in the cookie name. + +Replacing "·" with "-" in `wikiname` fixed this login issue. + +> Hmm, Recai sent me a patch a long time ago to handle utf-8 here by encoding +> the wikiname. But it doesn't seem to work, somehow the encoded utf-8 +> value still doesn't make it through. (CGI::Session seems to have underermined utf-8 +> issues too.) Seems like I will have to possibly break some sessions and +> entity-encode the wikiname in the cookie.. [[done]]. --[[Joey]] + +>> I confirm it fixes the bug for me. --[[intrigeri]] + +(BTW, such a char was replaced by -I don't remember what encoding thingie- in my setup file, when running `ikiwiki-transition setupformat`.) + +> Thanks for the heads up, fixed that too. --[[Joey]] + +>> I confirm it fixes the bug for me. --[[intrigeri]] diff --git a/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn b/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn new file mode 100644 index 000000000..d00f6815b --- /dev/null +++ b/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn @@ -0,0 +1,12 @@ +When I click on a linked username for commits on the recentchanges page (on +the live ikiwiki.info) I get a link such as +<http://ikiwiki.info/ikiwiki.cgi?page=users%2Fjoey&do=recentchanges_link> +which returns something like + + <a href="http://ikiwiki.info">ikiwiki</a>/ Error + <p class="error">Error: unknown do parameter + +-- [[Jon]] + +> That was fixed in 3.04 but ikiwiki.info had not been upgraded to it yet. +> [[done]] --[[Joey]] |