diff options
Diffstat (limited to 'doc/bugs')
30 files changed, 741 insertions, 1 deletions
diff --git a/doc/bugs/404_plugin_and_lighttpd.mdwn b/doc/bugs/404_plugin_and_lighttpd.mdwn index e478d98c3..8508d0dcd 100644 --- a/doc/bugs/404_plugin_and_lighttpd.mdwn +++ b/doc/bugs/404_plugin_and_lighttpd.mdwn @@ -1,5 +1,15 @@ Lighttpd apparently sets REDIRECT_STATUS=200 for the server.error-handler-404 page. This breaks the [[plugins/404]] plugin which checks this variable for 404 before processing the URI. It also doesn't seem to set REDIRECT_URL. +> For what it's worth, the first half is <http://redmine.lighttpd.net/issues/1828>. +> One workaround would be to make this script your 404 handler: +> +> #!/bin/sh +> REDIRECT_STATUS=404; export REDIRECT_STATUS +> REDIRECT_URL="$SERVER_NAME$REQUEST_URI"; export REDIRECT_URL +> exec /path/to/your/ikiwiki.cgi "$@" +> +> --[[smcv]] + I was able to fix my server to check the REQUEST_URI for ikiwiki.cgi and to continue processing if it was not found, passing $ENV{SEVER_NAME} . $ENV{REQUEST_URI} as the first parameter to cgi_page_from_404. However, my perl is terrible and I just made it work rather than figuring out exactly what to do to get it to work on both lighttpd and apache. This is with lighttpd 1.4.19 on Debian. diff --git a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn new file mode 100644 index 000000000..0082eed4d --- /dev/null +++ b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn @@ -0,0 +1,46 @@ +That one has bitten me for some time; here is the minimal testcase. There is +also an equivalent (I suppose) problem when using another plugin, but I hope +it's enough to track it down for this one. + + $ tar -xj < [bug-dep_order.tar.bz2](http://schwinge.homeip.net/~thomas/tmp/bug-dep_order.tar.bz2) + $ cd bug-dep_order/ + $ ./render_locally + [...] + $ find "$PWD".rendered/ -print0 | xargs -0 grep 'no text was copied' + $ [no output] + $ touch news/2010-07-31.mdwn + $ ./render_locally + refreshing wiki.. + scanning news/2010-07-31.mdwn + building news/2010-07-31.mdwn + building news.mdwn, which depends on news/2010-07-31 + building index.mdwn, which depends on news/2010-07-31 + done + $ find "$PWD".rendered/ -print0 | xargs -0 grep 'no text was copied' + /home/thomas/tmp/hurd-web/bug-dep_order.rendered/news.html:<p>[[!paste <span class="error">Error: no text was copied in this page</span>]]</p> + /home/thomas/tmp/hurd-web/bug-dep_order.rendered/news.html:<p>[[!paste <span class="error">Error: no text was copied in this page</span>]]</p> + +This error shows up only for *news.html*, but not in *news/2010-07-31* or for +the aggregation in *index.html* or its RSS and atom files. + +--[[tschwinge]] + +> So the cutpaste plugin, in order to support pastes +> that come before the corresponding cut in the page, +> relies on the scan hook being called for the page +> before it is preprocessed. +> +> In the case of an inline, this doesn't happen, if +> the page in question has not changed. +> +> Really though it's not just inline, it's potentially anything +> that preprocesses content. None of those things guarantee that +> scan gets re-run on it first. +> +> I think cutpaste is going beyond the intended use of scan hooks, +> which is to gather link information, not do arbitrary data collection. +> Requiring scan be run repeatedly could be a lot more work. +> +> Using `%pagestate` to store the cut content when scanning would be +> one way to fix this bug. It would mean storing potentially big chunks +> of page content in the indexdb. [[done]] --[[Joey]] diff --git a/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn index 1b9cb2e2d..275661fb8 100644 --- a/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn +++ b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn @@ -1 +1,3 @@ The [[plugins/highlight]] plugin hard codes some paths up the top of the plugin. This means that you need to edit the ikiwiki source if you have highlight installed in a non-standard location (e.g. if you have done a user-level install of the highlight package). + +> configurable now, [[done]] --[[Joey]] diff --git a/doc/bugs/More_permission_checking.mdwn b/doc/bugs/More_permission_checking.mdwn new file mode 100644 index 000000000..e56cda98b --- /dev/null +++ b/doc/bugs/More_permission_checking.mdwn @@ -0,0 +1,9 @@ +I'm often confused about permissions and I wish ikiwiki could stamp it's foot down and ensure all the permissions are correctly (canonically?) setup. + +I keep ending up having to `sudo chown -R :www-data` and `sudo chmod -R g+w` on srcdir, destdir. I'm never quite sure what is the best practice for the srcdirs' `/srv/git/` is. Currently everything looks like `hendry:www-data` with ug+rw. + +I think I've triggered these problems by (not thinking and) running `ikiwiki --rebuild --setup /home/hendry/.ikiwiki/mywiki.setup` as my user. + +I don't know if there can be some lookup with `/etc/ikiwiki/wikilist`. Though shouldn't everything be under the `www-data` group in reality? + +Also when I use `sudo ikiwiki -setup /etc/ikiwiki/auto.setup`, I think I create a ton of problems for myself since everything is created as the root user, right? And `/etc/ikiwiki/wikilist` doesn't seem to have the latest created wiki added. I have to reluctantly manually do this. diff --git a/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn b/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn new file mode 100644 index 000000000..21df334a8 --- /dev/null +++ b/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn @@ -0,0 +1,20 @@ +Wide characters should probably be supported, or, at the very least, warned about. + +Test case: + + mkdir -p ikiwiki-utf-test/raw ikiwiki-utf-test/rendered + for page in txt mdwn; do + echo hello > ikiwiki-utf-test/raw/$page.$page + for text in 8 16 16BE 16LE 32 32BE 32LE; do + iconv -t UTF$text ikiwiki-utf-test/raw/$page.$page > ikiwiki-utf-test/raw/$page-utf$text.$page; + done + done + ikiwiki --verbose --plugin txt --plugin mdwn ikiwiki-utf-test/raw/ ikiwiki-utf-test/rendered/ + www-browser ikiwiki-utf-test/rendered/ || x-www-browser ikiwiki-utf-test/rendered/ + # rm -r ikiwiki-utf-test/ # some browsers rather stupidly daemonize themselves, so this operation can't easily be safely automated + +BOMless LE and BE input is probably a lost cause. + +Optimally, UTF-16 (which is ubiquitous in the Windows world) and UTF-32 should be fully supported, probably by converting to mostly-UTF-8 and using `&#xXXXX;` or `&#DDDDD;` XML escapes where necessary. + +Suboptimally, UTF-16 and UTF-32 should be converted to UTF-8 where cleanly possible and a warning printed where impossible. diff --git a/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn b/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn new file mode 100644 index 000000000..3c3352f66 --- /dev/null +++ b/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn @@ -0,0 +1,12 @@ +At least at http://free-thursday.pieni.net/ikiwiki.cgi the "SSH keys" page shows only the first 139 characters of each SSH key. I'm using iceweasel in 1024x768 resolution and there are not scrollbars visible. + +Please contact me at timo.lindfors@iki.fi + +> I have access to the same wiki, and do not see the problem Timo sees. I see 380 chars of the SSH keys, and do have a scrollbar. +> Weird. --liw + +> Also, that's a Branchable.com site and the bug, if any is +> in ikiwiki-hosting's plugin, not ikiwiki proper. Moved +> [here](http://ikiwiki-hosting.branchable.com/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key/) --[[Joey]] + +[[!tag done]] diff --git a/doc/bugs/aggregate_generates_long_filenames.mdwn b/doc/bugs/aggregate_generates_long_filenames.mdwn new file mode 100644 index 000000000..fae8333ab --- /dev/null +++ b/doc/bugs/aggregate_generates_long_filenames.mdwn @@ -0,0 +1,37 @@ +the [[plugins/aggregate]] plugin mashes the `title` of an aggregated post into a filename. This results in long filenames. I have hit a filesystem length limitation on several occasions. Some (ab)uses of RSS, e.g., twitter, +generate long titles. Especially once you throw escaping into the mix: + + $ ikiwiki --setup testsetup --aggregate --refresh + failed to write ./test/lifestream/Hidden_Features_Of_Perl__44___PHP__44___Javascript__44___C__44___C++__44___C__35____44___Java__44___Ruby___46____46____46__._aggregated.ikiwiki-new: File name too long + aggregation failed with code 9216 + $ echo $? + 25 + +It would also appear this abrubtly terminates aggregate processing (if not ikiwiki itself). Only after moving my test repo to `/tmp` to shorten the filename did I see newer RSS feeds (from a totally different source) picked up. + + +-- [[Jon]] + +> I have to wonder what filesystem you have there where 147 characters +> is a long filename. Ikiwiki already uses `POSIX::pathconf` on the srcdir +> to look up `_PC_NAME_MAX` +> to see if the filename is too long, and shortens it, so it seems +> that, in additional to having a rather antique long filename limit, your +> system also doesn't properly expose it via pathconf. Not sure what +> ikiwiki can do here. --[[Joey]] + +>> This is an ext4 filesystem with default settings (which appears to mean +>> 256 bytes for pathnames). Despite the error saying file name, it's +>> definitely a path issue since moving my test repo to `/tmp`from +>> `/home/jon/wd/mine/www` hides the problem. I note the following comment +>> in `aggregate.pm`: + + # Make sure that the file name isn't too long. + # NB: This doesn't check for path length limits. + +>> I don't fully grok the aggregate source yet, but I wouldn't rule out +>> a bug in the path length checking, personally. I'm happy to try and +>> find it myself though :) -- [[Jon]] + +>>> Path length seems unlikely, since the max is 4096 there. +>>> --[[Joey]] diff --git a/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn new file mode 100644 index 000000000..ff98ba55f --- /dev/null +++ b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn @@ -0,0 +1,62 @@ +I get the following error when building my wiki + + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + +that line corresponds to + + sub match_creation_year ($$;@) { + if ((localtime($IkiWiki::pagectime{shift()}))[5] + 1900 == shift) { <-- this one + return IkiWiki::SuccessReason->new('creation_year matched'); + } + +A git bisect shows that the offending commit introduced this hunk + + + --- /dev/null + +++ b/templates/all_entry.mdwn + @@ -0,0 +1,23 @@ + +## <TMPL_VAR year> + + + +There + +<TMPL_IF current> + +have been + +<TMPL_ELSE> + +were + +</TMPL_IF> + +[[!pagecount pages=" + +log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + +and creation_year(<TMPL_VAR year>) + +and !*.png and !*.jpg + +"]] posts + +<TMPL_IF current> + +so far + +</TMPL_IF> + +in <TMPL_VAR year>. + + + +[[!inline pages=" + + log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + + and creation_year(<TMPL_VAR year>) + + and !*.png and !*.jpg + + " archive=yes feeds=no]] + +The lines which feature creation_year(<TMPL_VAR year>) are most likely the culprits. That would explain why the error was repeated twice, and would tally with the file in `templates/` being rendered, rather than the inclusionists. + +A workaround is to move the template outside of the srcdir into the external templates directory and include the file suffix when using it, e.g. + + \[[!template id=all_entry.tmpl year=2010 current=true]] + +I believed (until I tested) that the [[ikiwiki/directive/if]] directive, with the `included()` test, would be an option here, E.g. + + \[[!if test="included()" then=""" + ...template... + """ else=""" + Nothing to see here. + """]] + +However this doesn't work. I assume "included" in this context means e.g. via an `inline` or `map`, not template trans-clusion. -- [[Jon]] + +> As far as I know, this bug was fixed in +> 4a75dee651390b79ce4ceb1d951b02e28b3ce83a on October 20th. [[done]] --[[Joey]] + +>> Sorry Joey, I'll make sure to reproduce stuff against master in future. [[Jon]] diff --git a/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn b/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn new file mode 100644 index 000000000..59bf93d14 --- /dev/null +++ b/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn @@ -0,0 +1,15 @@ +Hi, + +I'm trying to add a comment, and ikiwiki fails with this error message: + + Error: HTTP::Message content must be bytes at /usr/share/perl5/RPC/XML/Client.pm line 308 + +This seems to happen because I had a non-ASCII character in the comment (an ellipse, …). +The interesting part is that the comment preview works fine, just the save fails. Probably +this means that the blogspam plugin is the culprit (hence the error in RPC::XML::Client library). +I'm using version 3.20100815~bpo50+. Thanks! + +> I've filed an upstream bug about this on RPC::XML: +> <https://rt.cpan.org/Ticket/Display.html?id=61333> +> +> Worked around it in blogspam by decoding. [[done]] --[[Joey]] diff --git a/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn b/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn new file mode 100644 index 000000000..e91a8923d --- /dev/null +++ b/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn @@ -0,0 +1,61 @@ +I often find myself wrapping the same boiler plate around [[ikiwiki/directives/img]] img directives, so I tried to encapsulate it using the following [[ikiwiki/directives/template]]: + + + <div class="image"> + [\[!img <TMPL_VAR raw_href> + size="<TMPL_VAR raw_size>" + + <TMPL_IF alt> + alt="<TMPL_VAR raw_alt>" + <TMPL_ELSE> + <TMPL_IF caption> + alt="<TMPL_VAR raw_alt>" + <TMPL_ELSE> + alt="[pic]" + </TMPL_IF> + </TMPL_IF> + + ]] + <TMPL_IF caption> + <p><TMPL_VAR raw_caption></p> + </TMPL_IF> + </div> + +The result, even with htmlscrubber disabled, is mangled, something like + + <div class="image"> + <span class="createlink"><a href="http://jmtd.net/cgi? + page=size&from=log0.000000old_new_test&do=create" + rel="nofollow">?</a>size</span> + + </div> + +Any suggestions gladly received. -- [[Jon]] + +> Well, you *should* be able to do things like this, and in my testing, I +> *can*. I used your exact example above (removing the backslash escape) +> and invoked it as: +> \[[!template id=test href=himom.png size=100x]] +> +> And got just what you would expect. +> +> I don't know what went wrong for you, but I don't see a bug here. +> My guess, at the moment, is that you didn't specify the required href +> and size parameters when using the template. If I leave those off, +> I of course reproduce what you reported, since the img directive gets +> called with no filename, and so assumes the size parameter is the image +> to display.. [[done]]? --[[Joey]] + +>> Hmm, eek. Just double-checked, and done a full rebuild. No dice! Version 3.20100831. Feel free to leave this marked done, It probably *is* PEBKAC. I shall look again in day time. -- [[Jon]] + +>>> As always, if you'd like to mail me a larger test case that reproduces a +>>> problem for you, I can take a look at it. --[[Joey]] + +>>>> <s>Thank you for the offer. I might still take you up on it. I've just proven that this +>>>> does work for a clean repo / bare bones test case. -- [[Jon]]</s> Figured it out. The +>>>> problem was I'd copied a page (old_new) which had two images embedded in it to test. +>>>> I'd stored the images under a subdir "old_new". The new page was called "old_new_test" +>>>> and the images thus could not be found by a pagespec "some-image.jpg". Adjusting the +>>>> href argument to the template (consequently the src argument to img) to +>>>> "old_new/some-image.jpg" fixed it all. [[done]], PEBKAC. Thank you for your time :) +>>>> -- [[Jon]] diff --git a/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn b/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn new file mode 100644 index 000000000..e7797765f --- /dev/null +++ b/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn @@ -0,0 +1,31 @@ +On [[ikiwiki/directive/img/]] I read that + +> You can also pass alt, title, class, align, id, hspace, and vspace +> parameters. These are passed through unchanged to the html img tag. + +but when I pass `class="myclass"` to an img directive, I obtain + + <img class="myclass img" ... + +I found that this behaviour was added in commit f6db10d: + +> img: Add a margin around images displayed by this directive. +> +> Particularly important for floating images, which could before be placed +> uncomfortably close to text. + +which adds to img.pm: + + if (exists $params{class}) { + $params{class}.=" img"; + } + else { + $params{class}="img"; + } + +I would prefer if the `img` class were only added if no class attribute is +passed. + +If you keep the current behaviour, please document it. + +> [[done]] --[[Joey]] diff --git a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn new file mode 100644 index 000000000..4b22fd06c --- /dev/null +++ b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn @@ -0,0 +1,55 @@ +Consider this: + + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2 + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch + + $ tar -xj < cutpaste_filter.tar.bz2 + $ cd cutpaste_filter/ + $ ./render_locally + $ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR' + [notice one FOO in there] + $ rm -rf .ikiwiki "$PWD".rendered + + $ cp /usr/share/perl5/IkiWiki/Plugin/cutpaste.pm .library/IkiWiki/Plugin/ + $ patch -p0 < ../cutpaste_filter.patch + $ ./render_locally + $ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR' + [correct; notice no more FOO] + +I guess this needs a general audit -- there are other places where `preprocess` +is being doing without `filter`ing first, for example in the same file, `copy` +function. + +--[[tschwinge]] + +> So, in English, page text inside a cut directive will not be filtered. +> Because the cut directive takes the text during the scan pass, before +> filtering happens. +> +> Commit 192ce7a238af9021b0fd6dd571f22409af81ebaf and +> [[bugs/po_vs_templates]] has to do with this. +> There I decided that filter hooks should *only* act on the complete +> text of a page. +> +> I also suggested that anything that wants to reliably +> s/FOO/BAR/ should probably use a sanitize hook, not a filter hook. +> I think that would make sense in this example. +> +> I don't see any way to make cut text be filtered while satisfying these +> constraints, without removing cutpaste's ability to have forward pastes +> of text cut laster in the page. (That does seems like an increasingly +> bad idea..) --[[Joey]] + +> > OK -- so the FOO/BAR thing was only a very stripped-down example, of +> > course, and the real thing is being observed with the +> > *[[plugins/contrib/getfield]]* plugin. This one needs to run *before* +> > `preprocess`ing, for its `{{$page#field}}` syntax is (a) meant to be usable +> > inside ikiwiki directives, and (b) the field values are meant to still be +> > `preprocess`ed before being embedded. That's why it's using the `filter` +> > hook instead of `sanitize`. + +> > Would adding another kind of hook be a way to fix this? My idea is that +> > *cut* (and others) would then take their data not during `scan`ning, but +> > *after* `filter`ing. + +> > --[[tschwinge]] diff --git a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn new file mode 100644 index 000000000..5dc4250e3 --- /dev/null +++ b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn @@ -0,0 +1,14 @@ +The _git_ module does not appear ever to prune obsolete remote branches in the _srcdir_ repository, leading to spurious errors when fetching. + +Pruning remote branches can be done automatically with the --prune option to "git fetch" or in a separate command "git remote prune". + +--[[blipvert]] + +> I'll need more information than that before I add extra processing +> work to the current git commands it uses. I don't see any errors here +> from obsolete remote branches. --[[Joey]] + +Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resources (any commits they point to cannot be garbage collected). --[[blipvert]] + +> Ok, so git pull --prune can be used to do everything in one command. +> [[done]] --[[Joey]] diff --git a/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn b/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn new file mode 100644 index 000000000..587650c61 --- /dev/null +++ b/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn @@ -0,0 +1,19 @@ +Commit 3650d0265bc501219bc6d5cd4fa91a6b6ecd793a seems to have been caused by +a bug in ikiwiki. recentchanges/* was added to the git repo incorrectly. + +Part of the problem seems to be that git's `rcs_commit` does a git add followed +by a `rcs_commit_staged`, and so calling `rcs_commit` on files that were +not checked in before adds them, incorrectly. + +I'm unsure yet why the recentchanges files were being committed. Possibly +because of the link fixup code run when renaming a page. --[[Joey]] + +> See also [[bugs/rename fixup not attributed to author]]. --[[smcv]] + +> Ok, there was a call to `rcs_commit` that was still using non-named +> parameters, which confused it thuroughly, and I think caused +> 'git add .' to be called. I've fixed that. +> +> I think there is still potential for the problem I described above to +> occur during a rename or possibly otherwise. Ok.. fixed `rcs_commit` +> to not add too. [[done]] --[[Joey]] diff --git a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn new file mode 100644 index 000000000..92427065d --- /dev/null +++ b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn @@ -0,0 +1,18 @@ +[[!template id=gitbranch branch=smcv/ready/htmlbalance author="[[smcv]]"]] +[[!tag patch]] + +My one-patch htmlbalance branch fixes incompatibility with HTML::Tree 4.0. +From the git commit: + + The HTML::Tree changelog says: + + [THINGS THAT MAY BREAK YOUR CODE OR TESTS] + ... + * Attribute names are now validated in as_XML and invalid names will + cause an error. + + and indeed the regression tests do get an error. + +--[[smcv]] + +[[done]] --[[Joey]] diff --git a/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn b/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn new file mode 100644 index 000000000..91507f57a --- /dev/null +++ b/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn @@ -0,0 +1,25 @@ +Someone tried to report a bug using IRC while I was on vacation. +--[[Joey]] + +<pre> +julm: [11:58:35] han, it's me the problem; I was generating a post-update hook instead of a pre-receive hook +julm: [12:03:59] why does the pre-receive hook return: "Status: 302 Found" and a "Location: <url>"? Is it normal? +julm: [00:08:44] it's Plugin/httpauth.pm which is outputing those Status and Location +julm: [00:09:12] problem is that it's an anonymous push via git:// +julm: [03:28:53] hacked my way to fix it somehow: http://git.internet.alpes.fr.eu.org/?p=web/ikiwiki.git;a=commitdiff;h=7211df4f7457c3afab53822a97cbd21825c473f4 +</pre> + +Analysis: + +* IkiWiki::Receive calls `check_canedit`. +* httpauth's canedit hook returns an error handler function + which redirects the browser through the cgiauthurl. + (Similarly, signinedit's hook may call needsignin, which + can display a signin form. +* That doesn't work well when doing a git anon push. :) +* Also, IkiWiki::Receive calls `check_canattach` and + `check_canremove`, which both also call `check_canedit`. + +So, all these calls need to avoid running the error handler +functions returned by canedit hooks, and just return error +messages. [[done]] --[[Joey]] diff --git a/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn b/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn new file mode 100644 index 000000000..6781d4b4b --- /dev/null +++ b/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn @@ -0,0 +1,24 @@ +At the very top of the main ikiwiki executable script the `PATH` environment is set like this: + + $ENV{PATH}="/usr/local/bin:/usr/bin:/bin:/opt/local/bin"; + +This makes it a little hard to specify which specific binaries should be used, especially if there is more than one of them available (see c.f. <http://trac.macports.org/ticket/26333> where the MacPorts-supplied, up-to-date subversion should be used and not an arcane one from the base distro / OS). Is there a specific reason why ikiwiki wipes out `$PATH` like this or could that line be improved to + + $ENV{PATH}="$ENV{PATH}:/usr/local/bin:/usr/bin:/bin:/opt/local/bin"; + +? The alternative is of course to patch ikiwiki as suggested in the bug, but I wanted to ask here first :) + +> You can use the ENV setting in your setup file to set any environment +> variables you like. Since ikiwiki.cgi is run by the web browser, that +> is the best way to ensure ikiwiki always runs with a given variable set. +> +> As a suid program, the ikiwiki wrappers have to sanitize the environment. +> The ikiwiki script's own sanitization of PATH was done to make perl taint +> checking happy, but as taint checking is disabled anyway, I have removed +> that. [[done]] --[[Joey]] + +Question: Do ikiwiki.cgi and the RCS post-commit script sanitize the $PATH separately from bin/ikiwiki? If not, then bin/ikiwiki is probably right to sanitize the $PATH; otherwise you've created a security hole with access to the account that ikiwiki is SUID to. It'd be nice if /opt/local/bin were earlier in the $PATH, but that can be changed (as noted) in the setup file. [[Glenn|geychaner@mac.com]] (Also the person who started this by filing an issue with MacPorts; I'm experimenting with ikiwiki for collaborative documentation.) + +> The suid wrappers remove all environment variables except for a few used +> for CGI. PATH is not propigated by them, so when they run ikiwiki it will +> get the system's default path now. --[[Joey]] diff --git a/doc/bugs/img_plugin_and_class_attr.mdwn b/doc/bugs/img_plugin_and_class_attr.mdwn new file mode 100644 index 000000000..7e880b4fc --- /dev/null +++ b/doc/bugs/img_plugin_and_class_attr.mdwn @@ -0,0 +1,27 @@ +The [[plugins/img]] plugin is not generating the proper `class` +attribute in its HTML output. + +The plugin receives something like the following: + + \[[!img 129199047595759991.jpg class="centered"]] + +And is supossed to generate an HTML code like the following: + + <img src="129199047595759991.jpg" class="centered" /> + +But is generating the following + + <img src="129199047595759991.jpg" class="centered img" /> + +This seems to be happening with all images inserted using the plugin (that use +the `class=yaddayadda` argument to the `img` directive.) I remember it didn't +happen before, and I suspect an ikiwiki upgrade is to blame. I tested with a +blog created from scratch, and a single post, and the problem appeared there +too. + +This is happening with version 3.20100815 of ikiwiki. + +[[jerojasro]] + +> How is this a bug? It's perfectly legal html for a class attribute to +> put an element into multiple classes. [[notabug|done]] --[[Joey]] diff --git a/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn new file mode 100644 index 000000000..45481bf21 --- /dev/null +++ b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn @@ -0,0 +1,13 @@ +ikiwiki verison: 3.20100815.2 + +If I instruct editemplate to only match the top level pages in a directory using + + match="foo/* and !foo/*/* and !foo/*/*/*" + +everything works as expected for pages created via links on other wiki pages. So, if I open foo/bar (or any other page on the wiki) and create a link to foo/bar/bug, edittemplate appropriately does not insert any text into the new page. + +However, if I use an inline directive like the following + + !inline pages="page(foo/bar/*)" rootpage="foo/bar" postform=yes actions=yes + +every page created via the action buttons incorrectly pulls in the text from the edittemplate registration. Changing the order of the conditions in the match="" pagespec has no impact. diff --git a/doc/bugs/logout_in_ikiwiki.mdwn b/doc/bugs/logout_in_ikiwiki.mdwn new file mode 100644 index 000000000..d9b6df677 --- /dev/null +++ b/doc/bugs/logout_in_ikiwiki.mdwn @@ -0,0 +1,31 @@ +It looks like there is no way to logout of ikiwiki at present, meaning that if you edit the ikiwiki in, say, a cybercafe, the cookie remains... is there some other security mechanism in place that can check for authorization, or should I hack in a logout routine into ikiwiki.cgi? + +> Click on "Preferences". There is a logout button there. --liw + +> It would be nice if it were not buried there, but putting it on the +> action bar statically would be confusing. The best approach might be to +> use javascript. --[[Joey]] + + +>> I agree that javascript seems to be a solution, but my brain falls +>> off the end of the world while looking at ways to manipulate the DOM. +>> (I'd argue also in favor of the openid_provider cookie expiring +>> in less time than it does now, and being session based) + +>>> (The `openid_provider` cookie is purely a convenience cookie to +>>> auto-select the user's openid provider the next time they log +>>> in. As such, it cannot be a session cookie. It does not provide any +>>> personally-identifying information so it should not really matter +>>> when it expires.) --[[Joey]] + +>> It would be nice to move navigational elements to the upper right corner +>> of the page... + +>> I have two kinds of pages (wiki and blog), and three classes of users + +>> anonymous users - display things like login, help, and recentchanges, + +>> non-admin users - on a per subdir basis (blog and !blog) display +>> logout, help, recentchanges, edit, comment + +>> admin users - logout, help, recentchanges, edit, comment, etc diff --git a/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn b/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn new file mode 100644 index 000000000..35f624f78 --- /dev/null +++ b/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn @@ -0,0 +1,5 @@ +The [[rcs/monotone]] backend does not currently support putting the ikiwiki srcdir +in a subdirectory of the repository. It must be at the top. Git has +special code to handle this case. --[[Joey]] + +[[done]] diff --git a/doc/bugs/more_and_RSS_generation.mdwn b/doc/bugs/more_and_RSS_generation.mdwn new file mode 100644 index 000000000..00ab43fa2 --- /dev/null +++ b/doc/bugs/more_and_RSS_generation.mdwn @@ -0,0 +1,20 @@ +I'd like the more plugin and RSS to play better together. In the case of the html generation of the main page of a blog, I'd like to get the first paragraph out, but keep RSS as a full feed. + +Maybe there is a different plugin (I also tried toggle)? + +> I am not a fan of the more directive (thus the rant about it sucking +> embedded in its [[example|ikiwiki/directive/more]]). But I don't think +> that weakening it to not work in rss feeds is a good idea, if someone +> wants to force users to go somewhere to view their full content, +> they should be able to do it, even though it does suck. +> +> The toggle directive will degrade fairly well in an rss feed to +> display the full text. (There is an annoying toggle link that does +> nothing when embedded in an rss feed). --[[Joey]] + +I also note, that at least currently, more seems to break on a few pages, not being parsed at all when aggregated into the front page. + +> It's just a simple directive, it should work anywhere any directive will, +> and does as far as I can see. Details? --[[Joey]] + +see also: [[/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields/]] diff --git a/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn b/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn new file mode 100644 index 000000000..a2b68c4b1 --- /dev/null +++ b/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn @@ -0,0 +1,36 @@ +The apache config documented in [[plugins/po]] has a subtle bug. It works +until a site gets an index.atom or index.rss file. (Acutally, with po +enabled, they're called index.en.atom or index.en.rss etc, but the result +is the same). + +Then, when wget, curl, or w3m is pointed at http://site/, apache serves +up the rss/atom file rather than the index page. + +Analysis: + +* /etc/mime.types gives mime types to .rss and .atom files +* `mod_negotiation`'s MultiViews allows any file with a mime type to be + served up via content negotiation, if the client requests that type. +* wget etc send `Accept: */*` to accept all content types. Compare + with firefox, which sends `Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*` +* So apache has a tie between a html encoded Enlish file, and a rss encoded + English file and the client has no preference. In a tie, apache will serve up the + *smallest* file, which tends to be the rss file. (Apache's docs say it uses that + strange criteria to break ties; see <http://httpd.apache.org/docs/2.0/mod/mod_mime.html#multiviewsmatch>) + +The only way I have found to work around this problem is to remove +atom and rss from /etc/mime.types. Of course, that has other undesirable +results. + +I wonder if it would be worth making the po plugin generate apache +[type map files](http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html#typemaps). +That should avoid this problem. +--[[Joey]] + +Update: A non-intrusive fix is to add this to apache configuration. +This tunes the "quality" of the rss and atom files, in an apparently currently +undocumented way (though someone on #httpd suggested it should get documented). +Result is that apache will prefer serving index.html. --[[Joey]] [[done]] + + AddType application/rss+xml;qs=0.8 .rss + AddType application/atom+xml;qs=0.8 .atom diff --git a/doc/bugs/po:_markdown_link_parse_bug.mdwn b/doc/bugs/po:_markdown_link_parse_bug.mdwn new file mode 100644 index 000000000..10715001c --- /dev/null +++ b/doc/bugs/po:_markdown_link_parse_bug.mdwn @@ -0,0 +1,14 @@ +Apparently this is legal markdown, though unusual syntax for a link: + + [Branchable](http://www.branchable.com/ "Ikiwiki hosting") + +If that is put on a translatable page, the translations display it not as a +link, but as plain text. + +Probably a po4a bug, but I don't see the bug clearly in the gernerated po +file: + + "This was posted automatically by [Branchable](http://www.branchable.com/ " + "\"Ikiwiki hosting\") when I signed up." + +--[[Joey]] diff --git a/doc/bugs/po:_po_files_instead_of_html_files.mdwn b/doc/bugs/po:_po_files_instead_of_html_files.mdwn index 933e348c4..8238f50df 100644 --- a/doc/bugs/po:_po_files_instead_of_html_files.mdwn +++ b/doc/bugs/po:_po_files_instead_of_html_files.mdwn @@ -3,4 +3,20 @@ At the bottom of this page, there is the "Links" line: Links: index index.fr templates templates.fr When i click on "templates.fr", i get the po.file instead of html. - Sorry for the noise! I set "po_master_language" to fr and all was ok. [[done]]. + Sorry for the noise! I set "po_master_language" to fr and all was ok. + +> Any chance you could be a bit more verbose about what the +> misconfiguration was? I don't think the po plugin should behave like that +> in any configuration. Unless, perhaps, it was just not configured to +> support any languages at all, and so the po file was treated as a raw +> file. --[[Joey]] + +>> I can reproduce the bug with: + # po plugin + # master language (non-PO files) + po_master_language => { + code => 'en', + name => 'English' + }, + # slave languages (PO files) + po_slave_languages => [qw{fr|Français}], diff --git a/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn b/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn new file mode 100644 index 000000000..121d33807 --- /dev/null +++ b/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn @@ -0,0 +1,73 @@ +broken links to translatable basewiki pages that lack po files +-------------------------------------------------------------- + +If a page is not translated yet, the "translated" version of it +displays wikilinks to other, existing (but not yet translated?) +pages as edit links, as if those pages do not exist. + +That's really confusing, especially as clicking such a link +brings up an edit form to create a new, english page. + +This is with po_link_to=current or negotiated. With default, it doesn't +happen.. + +Also, this may only happen if the page being linked to is coming from an +underlay, and the underlays lack translation to a given language. +--[[Joey]] + +> Any simple testcase to reproduce it, please? I've never seen this +> happen yet. --[[intrigeri]] + +>> Sure, go here <http://l10n.ikiwiki.info/smiley/smileys/index.sv.html> +>> (Currently 0% translateed) and see the 'WikiLink' link at the bottom, +>> which goes to <http://l10n.ikiwiki.info/ikiwiki.cgi?page=ikiwiki/wikilink&from=smiley/smileys&do=create> +>> Compare with eg, the 100% translated Dansk version, where +>> the WikiLink link links to the English WikiLink page. --[[Joey]] + +>>> Seems not related to the page/string translation status: the 0% +>>> translated Spanish version has the correct link, just like the +>>> Dansk version => I'm changing the bug title accordingly. +>>> +>>> I tested forcing the sv html page to be rebuilt by translating a +>>> string in it, it did not fix the bug. I did the same for the +>>> Spanish page, it did not introduce the bug. So this is really +>>> weird. +>>> +>>> The smiley underlay seems to be the only place where the wrong +>>> thing happens: the basewiki underlay has similar examples +>>> that do not exhibit this bug. An underlay linking to another might +>>> be necessary to reproduce it. Going to dig deeper. --[[intrigeri]] + +>>>> After a few hours lost in the Perl debugger, I think I have found +>>>> the root cause of the problem: in l10n wiki's configured +>>>> `underlaydir`, the basewiki is present in every slave language +>>>> that is enabled for this wiki *but* Swedish. With such a +>>>> configuration, the `ikiwiki/wikilink` page indeed does not exist +>>>> in Swedish language: no `ikiwiki/wikilink.sv.po` can be found +>>>> where ikiwiki is looking. Have a look to +>>>> <http://l10n.ikiwiki.info/ikiwiki/>, the basewiki is not +>>>> available in Swedish language on this wiki. So this is not a po +>>>> bug, but a configuration or directories layout issue. This is +>>>> solved by adding the Swedish basewiki to the underlay dir, which +>>>> is I guess not a possibility in the l10n wiki context. I guess +>>>> this could be solved by adding `SRCDIR/basewiki` as an underlay +>>>> to your l10n wiki configuration, possibly using the +>>>> `add_underlays` configuration directive. --[[intrigeri]] + +>>>>> There is no complete Swedish underlay translation yet, so it is not +>>>>> shipped in ikiwiki. I don't think it's a misconfiguration to use +>>>>> a language that doesn't have translated underlays. --[[Joey]] + +>>>>>> Ok. The problem is triggered when using a language that doesn't +>>>>>> have translated underlays, *and* defining +>>>>>> `po_translatable_pages` in a way that renders the base wiki +>>>>>> pages translatable in po's view of things, which in turns makes +>>>>>> the po plugin act as if the translation pages did exist, +>>>>>> although they do not in this case. I still need to have a deep +>>>>>> look at the underlays-related code you added to `po.pm` a while +>>>>>> ago. Stay tuned. --[[intrigeri]] + +>>>>>>> Fixed in my po branch, along with other related small bugs that +>>>>>>> happen in the very same situation only. --[[intrigeri]] + +>>>>>>>> Merged. Not tested yet, but I trust you; [[done]] --[[Joey]] diff --git a/doc/bugs/rename_fixup_not_attributed_to_author.mdwn b/doc/bugs/rename_fixup_not_attributed_to_author.mdwn new file mode 100644 index 000000000..bcfafac22 --- /dev/null +++ b/doc/bugs/rename_fixup_not_attributed_to_author.mdwn @@ -0,0 +1,12 @@ +When I renamed `todo/transient_in-memory_pages` to [[todo/transient pages]], +`rename::fixlinks` was meant to blame me for the link-fixing commit, and title it +`update for rename of %s to %s`. Instead, it blamed Joey for the commit, +and didn't set a commit message. + +(It also committed a pile of recentchanges pages which shouldn't have +been committed, for which see [[bugs/git_commit_adds_files_that_were_not_tracked]].) + +--[[smcv]] + +> It was calling `rcs_commit` old-style, and so not passing the session +> object that is used to get the user's name. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn index 48c168997..0a435cea3 100644 --- a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn +++ b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn @@ -34,3 +34,19 @@ For Atom, at least, I believe adding `type="xhtml"` to the title element will wo > Update: Ok, I've fixed this for titles, as a special case, but the > underlying problem remains for other fields in rss feeds (such as > author), so I'm leaving this bug report open. --[[Joey]] + +>> I'm curious if there has been any progress on better RSS output? +>> I've been prototyping a new blog and getting good RSS out of it +>> seems important as the bulk of my current readers use RSS. +>> I note, in passing that the "more" plugin doesn't quite do what +>> I want either - I'd like to pass a full RSS feed of a post and only +>> have "more" apply to the front page of the blog. Is there a way to do that? +>> -- [[dtaht]] +>> +>>> To be clear, the RSS spec sucks to such an extent that, as far as +>>> I know, there is no sort of title escaping that will work in all +>>> RSS consumers. Titles are currently escaped in the way +>>> that tends to break the fewest according to what I've read. +>>> If you're unlucky enough to +>>> have a "&" or "<" in your **name**, then you may still run into +>>> problems with how that is escaped in rss feeds. --[[Joey]] diff --git a/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn b/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn index dab3b7e5b..99e46aac9 100644 --- a/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn +++ b/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn @@ -24,3 +24,6 @@ throwing code..): > No, still the same failure. I think it's failing parsing the input data, > (which perl probably transmitted as an int due to perl internals) > not writing out its response. --[[Joey]] + +> On second thought, this was a bug in ikiwiki, it should be transmitting +> that as a string. Fixed in external.pm --[[Joey]] diff --git a/doc/bugs/web_reversion_on_ikiwiki.info.mdwn b/doc/bugs/web_reversion_on_ikiwiki.info.mdwn new file mode 100644 index 000000000..6f18cfcba --- /dev/null +++ b/doc/bugs/web_reversion_on_ikiwiki.info.mdwn @@ -0,0 +1,14 @@ +I created [[sandbox/revert me]] and then tried the revert button on +[[recentchanges]], but I was not allowed to revert it. The specific error +was + + Error: you are not allowed to change sandbox/revert_me.mdwn + +I've just tried reading through the revert code, and I haven't figured out +what permission I am lacking. Perhaps the error message could be a little +clearer on that. The error might have been thrown by git_parse_changes in +git.pm or check_canchange in IkiWiki.pm, via IkiWiki::Receive. -- Jon + +[[fixed|done]] --[[Joey]] + +: Brilliant, many thanks. -- [[Jon]] |