diff options
Diffstat (limited to 'doc/bugs')
12 files changed, 171 insertions, 1 deletions
diff --git a/doc/bugs/Insecure_dependency_in_mkdir.mdwn b/doc/bugs/Insecure_dependency_in_mkdir.mdwn index 5410ebbfd..46011a7e8 100644 --- a/doc/bugs/Insecure_dependency_in_mkdir.mdwn +++ b/doc/bugs/Insecure_dependency_in_mkdir.mdwn @@ -151,3 +151,10 @@ dubious >>>>>> You can check it out for yourself by pulling my fork of this, at github or my local repo. >>>>>> github will probably be faster for you: git://github.com/kjikaqawej/ikiwiki-simon.git --[[simonraven]] +>>>>>>> I don't know what I'm supposed to see in your github tree.. it +>>>>>>> looks identical to an old snapshot of ikiwiki's regular git repo? +>>>>>>> If you want to put up the .deb you're using, I could examine that. +>>>>>>> +>>>>>>> I was in fact able to reproduce the insecure dependency in mkdir +>>>>>>> message -- but only if I run 'perl -T ikiwiki'. +>>>>>>> --[[Joey]] diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn index bd895127a..5519e45c6 100644 --- a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn +++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn @@ -1,3 +1,21 @@ If I have a <--#include virtual="foo" --> in some file, it gets stripped, even though other HTML comments don't get stripped. I imagine it's some plugin doing it, or IkiWiki itself, or an IkiWiki dependency, but I haven't found where this is happening. I'm trying to implement a workaround for my sidebars forcing a rebuild of the wiki every day - I use the calendar plugin - when the day changes, by using SSI. > It is probably the [[plugins/htmlscrubber]] plugin. -- [[Jon]] + +> htmlscrubber does strip these, because they look like +> a html tag to it, not a html comment. (html comments start +> with `<!--` .. of course, they get stripped too, because +> they can be used to hide javascript..) +> +> Anyway, it makes sense for the htmlscrubber to strip server-side +> includes because otherwise your wiki could be attacked +> by them being added to it. If you want to use both the htmlscrubber and +> SSI together, I'd suggest you modify the [[wikitemplates]] +> and put the SSI on there. +> +> Ie, `page.tmpl` has a +> div that the sidebar is put into; if you just replace +> that with the SSI that includes your static sidebar, +> you should be good to go. --[[Joey]] + +[[done]] diff --git a/doc/bugs/__34__more__34___doesn__39__t_work.mdwn b/doc/bugs/__34__more__34___doesn__39__t_work.mdwn new file mode 100644 index 000000000..b2d929f13 --- /dev/null +++ b/doc/bugs/__34__more__34___doesn__39__t_work.mdwn @@ -0,0 +1,17 @@ +As one can see at [[plugins/more/discussion]], the [[plugins/more]] plugin doesn't work --- it renders as: + + <p><a name="more"></a></p> + + <p>This is the rest of my post. Not intended for people catching up on + their blogs at 30,000 feet. Because I like to make things + difficult.</p> + +No way to toggle visibility. +-- Ivan Z. + +> More is not about toggling visibility. Perhaps you want +> [[plugins/toggle]] More is about displaying the whole page +> content when it's a standalone page, and only displaying a fragment when +> it's inlined into a blog. --[[Joey]] [[done]] + +>> I see, thanks for bothering with the reply, I didn't understand this. --Ivan Z. diff --git a/doc/bugs/aggregate_global_feed_names.mdwn b/doc/bugs/aggregate_global_feed_names.mdwn new file mode 100644 index 000000000..27127ce27 --- /dev/null +++ b/doc/bugs/aggregate_global_feed_names.mdwn @@ -0,0 +1,13 @@ +[[plugins/aggregate]] takes a name parameter that specifies a global name +for a feed. This causes some problems: + +* If a site has multiple pages that aggregate, and they use the same + name, one will win and get the global name, the other will claim it's + working, but it's really showing what the other aggregated. +* If an aggregate directive is moved from page A to page B, and the wiki + refreshed, aggregate does not realize the feed moved, and so it will + keep aggregated pages under `A/feed_name/*`. To work around this bug, + you have to delete A, refresh (maybe with --aggregate?), and then add B. + +Need to find a way to not make the name be global. Perhaps it needs to +include the name of the page that contains the directive? diff --git a/doc/bugs/complex_wiki-code___40__braces__41___in_wikilink-text_breaks_wikilinks.mdwn b/doc/bugs/complex_wiki-code___40__braces__41___in_wikilink-text_breaks_wikilinks.mdwn new file mode 100644 index 000000000..364fae394 --- /dev/null +++ b/doc/bugs/complex_wiki-code___40__braces__41___in_wikilink-text_breaks_wikilinks.mdwn @@ -0,0 +1,9 @@ +Example (from [here](http://git.ikiwiki.info/?p=ikiwiki;a=blobdiff;f=doc/todo/matching_different_kinds_of_links.mdwn;h=26c5a072bf3cb205b238a4e6fd0882583a0b7609;hp=1d7c78d9065d78307b43a1f58a53300cde4015fa;hb=9b4c83127fdef0ceb682c104db9bfb321b17022e;hpb=df4cc4c16ca230ee99b80c80043ba54fb95f6e71)): +<pre> +[[`\[[!taglink TAG\]\]`|plugins/tag]] +</pre> +gives: + +[[`\[[!taglink TAG\]\]`|plugins/tag]] + +Expected: there is a [[ikiwiki/wikilink]] with the complex text as the displayed text. --Ivan Z. diff --git a/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn b/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn new file mode 100644 index 000000000..8cb47f864 --- /dev/null +++ b/doc/bugs/firefox_doesn__39__t_want_to_load_updated_pages_at_ikiwiki.info.mdwn @@ -0,0 +1,5 @@ +I'm using firefox-3.0.8-alt0.M41.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4pre) Gecko/2008100921 Firefox/3.0). I have noticed that quite often it shows an old state of a page at http://ikiwiki.info, e.g., [[recentchanges]] without my last edits, or the last page I edited (say, 50 min ago) in the state it was before I edited it. + +Only explicitly pressing "reload" helps. + +Is it a bug? I haven't been noticing such problems usually on other sites. --Ivan Z. diff --git a/doc/bugs/goto_with_bad_page_name.mdwn b/doc/bugs/goto_with_bad_page_name.mdwn new file mode 100644 index 000000000..bc462c840 --- /dev/null +++ b/doc/bugs/goto_with_bad_page_name.mdwn @@ -0,0 +1,25 @@ +If goto is passed a page name that +contains spaces or is otherwise not a valid page name, +it will display a "page does not exist", with a create link. But, +clicking on the link will result in "bad page name". + +I have found at least two ways it can happen: + +* If 404 is enabled, and the user goes to "http://wiki/some page with spaces" +* If mercurial is used, it pulls the user's full name, with spaces, + out for `rcs_recentchanges` and that ends up on RecentChanges. + +When fixing, need to keep in mind that we can't just run the input through +titlepage, since in all other circumstances, the page name is already valid +and we don't want to doubly-encode it. + +Seems like the goto plugin needs to check if the page name is valid and +pass it through titlepage if not. + +(As a side effect of this, 404 will start redirecting "http://wiki/some page +with spaces" to "http://wiki/some_page_with_spaces", if the latter exists. +That seems like a fairly good thing.) + +[[done]] + +--[[Joey]] diff --git a/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn b/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn index 85c2d0c6c..1c1cbbb73 100644 --- a/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn +++ b/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn @@ -7,3 +7,17 @@ with a template definition like <div id="foo">\[[!inline ... pages="<TMPL_VAR raw_pages>"]]</div> It would be much more convenient if the loop over pages happened in the template, allowing me to just stick whatever markup I want around the loop. + +> Unfortunatly, I don't think this can be changed at this point, +> it would probably break a lot of stuff that relies on the current +> template arrangement, both in ikiwiki's internals and in +> people's own, customised inline templates. (Also, I have some plans +> to allow a single inline to use different templates for different +> sorts of pages, which would rely on the current one template per +> page approach to work.) +> +> But there is a simple workaround.. the first template in +> an inline has FIRST set, and the last one has LAST set. +> So you can use that to emit your div or table top and bottom. +> +> [[done]] --[[Joey]] diff --git a/doc/bugs/pagecount_is_broken.mdwn b/doc/bugs/pagecount_is_broken.mdwn new file mode 100644 index 000000000..101230d94 --- /dev/null +++ b/doc/bugs/pagecount_is_broken.mdwn @@ -0,0 +1,3 @@ +The [[plugins/pagecount]] plugin seems to be broken, as it claims there are [[!pagecount ]] pages in this wiki. (if it's not 0, the bug is fixed) + +[[fixed|done]] --[[Joey]] diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn index f78d50c3c..1d99370f6 100644 --- a/doc/bugs/support_for_openid2_logins.mdwn +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -8,3 +8,10 @@ I've contacted JanRain who have pointed me to: * 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. :( + +> Both of the projects referenced above have since been released. +> Net::OpenID::Consumer 0.x in Debian is indeed only an OpenID 1 +> implementation. However, Net::OpenID::Consumer 1.x claims to be +> an OpenID 2 implementation (it's the second of the projects +> above). I've filed a bug in Debian asking for the package to be +> updated. --[[smcv]] diff --git a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn index 1bd556f50..e7e4af7c3 100644 --- a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn +++ b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn @@ -1,7 +1,10 @@ It may be that I'm simply misunderstanding something, but what is the rationale for having `tagged()` also match normal wikilinks? -> It simply hasn't been implemented yet -- see the answer in [[todo/tag_pagespec_function]]. Tags and wikilinks share the same underlying implementation, although ab reasonable expectation is that they are kept separate. --Ivan Z. +> It simply hasn't been implemented yet -- see the answer in +> [[todo/tag_pagespec_function]]. Tags and wikilinks share the same +> underlying implementation, although ab reasonable expectation is that +> they are kept separate. --Ivan Z. The following situation. I have `tagbase => 'tag'`. On some pages, scattered over the whole wiki, I use `\[[!tag open_issue_gdb]]` to declare that this page @@ -15,3 +18,16 @@ this is due to the wikilink being equal to a `\[[!tag ...]]`. What's the rationale on this, or what am I doing wrong, and how to achieve what I want? --[[tschwinge]] + +> What you are doing "wrong" is putting non-tag pages (i.e. +> `/tag/open_issues_gdb.mdwn`) under your tagbase. The rationale for +> implementing tag as it has been, I think, is one of simplicity and +> conciseness. -- [[Jon]] + +>> No, he has no pages under tagbase that aren't tags. This bug +>> is valid. [[todo/matching_different_kinds_of_links]] is probably +>> how it will eventually be solved. --[[Joey]] + +> And this is an illustration why a clean work-around (without changing the software) is not possible: while thinking about [[todo/matching_different_kinds_of_links]], I thought one could work around the problem by simply explicitly including the kind of the relation into the link target (like the tagbase in tags), and by having a separate page without the "tagbase" to link to when one wants simply to refer to the tag without tagging. But this won't work: one has to at least once refer to the real tag page if one wants to talk about it, and this reference will count as tagging (unwanted). --Ivan Z. + +> But well, perhaps there is a workaround without introducing different kinds of links. One could modify the [[tag plugin|plugins/tag]] so that it adds 2 links to a page: for tagging -- `tagbase/TAG`, and for navigation -- `tagdescription/TAG` (displayed at the bottom). Then the `tagdescription/TAG` page would hold whatever list one wishes (with `tagged(TAG)` in the pagespec), and whenever one wants to merely refer to the tag, one should link to `tagdescription/TAG`--this link won't count as tagging. So, `tagbase/TAG` would become completely auxiliary (internal) link targets for ikiwiki, the users would edit or link to only `tagdescription/TAG`. --Ivan Z. diff --git a/doc/bugs/unwanted_discussion_links_on_discussion_pages.mdwn b/doc/bugs/unwanted_discussion_links_on_discussion_pages.mdwn new file mode 100644 index 000000000..c74a094ce --- /dev/null +++ b/doc/bugs/unwanted_discussion_links_on_discussion_pages.mdwn @@ -0,0 +1,36 @@ +Background: some po translations (amongst which `fr.po`) translate "discussion" to an upper-cased word (in French: "Discussion"). +By the way, this is wished e.g. in German, where such a noun has to be written with an upper-cased "D", but I can not see +the logic behind the added "D" in French. + +Anyway, this gettext-translated word is used to name the discussion pages, as `$discussionlink` in `Render.pm` is +built from `gettext("discussion")`. In the same piece of code, a case-sensitive regexp that tests wether the page +being rendered is a discussion page is case-sensitive. + +On the other hand, new discussion pages are created with a name built from `gettext("Discussion")` (please note the upper-cased +"D"). Such a new page name seems to be automagically downcased. + +This leads to newly created discussion pages not being recognized as discussion pages by the +`$page !~ /.*\/\Q$discussionlink\E$/` regexp, so that then end with an unwanted discussion link. + +A simple fix that seems to work is to make this regexp case-insensitive: + + git diff IkiWiki/Render.pm + diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm + index adae9f0..093c25b 100644 + --- a/IkiWiki/Render.pm + +++ b/IkiWiki/Render.pm + @@ -77,7 +77,7 @@ sub genpage ($$) { + } + if ($config{discussion}) { + my $discussionlink=gettext("discussion"); + - if ($page !~ /.*\/\Q$discussionlink\E$/ && + + if ($page !~ /.*\/\Q$discussionlink\E$/i && + (length $config{cgiurl} || + exists $links{$page."/".$discussionlink})) { + $template->param(discussionlink => htmllink($page, $page, gettext("Discussion"), noimageinline => 1, forcesubpage => 1)); + +But the best way would be to avoid assuming implicitely that translators will translate "discussion" and "Discussion" the same way. + +> [[done]] --[[Joey]] + +[[!tag patch]] |