diff options
Diffstat (limited to 'doc/bugs')
13 files changed, 326 insertions, 47 deletions
diff --git a/doc/bugs/Insecure_dependency_in_mkdir.mdwn b/doc/bugs/Insecure_dependency_in_mkdir.mdwn index 67b30e687..28304b3d3 100644 --- a/doc/bugs/Insecure_dependency_in_mkdir.mdwn +++ b/doc/bugs/Insecure_dependency_in_mkdir.mdwn @@ -82,3 +82,48 @@ I can't see any related entries. Any ideas? >>> Ubuntu Gutsy also has Perl 5.8.8-7, so probably it has the bug too. >>> --[[Paweł|ptecza]] + +>>>> I just got it while building my latest version of git.ikiwiki.info + my stuff. +>>>> Only thing different in my version in IkiWiki.pm is that I moved a </a> over +>>>> a word (for createlink), and disabled the lowercasing of created pages. Running +>>>> Lenny's Perl. --[[simonraven]] + +>>>> Simon, I'm not clear what version of ikiwiki you're using. +>>>> Since version 2.40, taint checking has been disabled by +>>>> default due to the underlying perl bug. Unless you +>>>> build ikiwiki with NOTAINT=0. --[[Joey]] + +>>>> Hi, nope not doing this. Um, sorry, v. 3.13. I've no idea why it suddenly started doing this. +>>>> It wasn't before. I've been messing around IkiWiki.pm to see if I can set +>>>> a umask for `mkdir`. + +line 775 and down: ++ umask ($config{umask} || 0022); + +>>>> I figured it *might* be the `umask`, but I'll see in a few when / if it gets past that in the build. No; I keep getting garbage during the brokenlinks test + +<pre> +t/basewiki_brokenlinks.....Insecure dependency in mkdir while running with -T switch at IkiWiki.pm line 776. + +# Failed test at t/basewiki_brokenlinks.t line 11. + +# Failed test at t/basewiki_brokenlinks.t line 19. + + +broken links found +<li>shortcut from <a href="./shortcuts/">shortcuts</a></li></ul> + + + +# Failed test at t/basewiki_brokenlinks.t line 25. +Insecure dependency in mkdir while running with -T switch at IkiWiki.pm line 776. + +# Failed test at t/basewiki_brokenlinks.t line 11. + +# Failed test at t/basewiki_brokenlinks.t line 25. +# Looks like you failed 5 tests of 12. +dubious + Test returned status 5 (wstat 1280, 0x500) +</pre> + +>>>> I get this over and over... I haven't touched that AFAICT, at all. --[[simonraven]] diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn new file mode 100644 index 000000000..bd895127a --- /dev/null +++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn @@ -0,0 +1,3 @@ +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]] 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 f2c60309b..059415819 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 @@ -4,17 +4,19 @@ If I click on "Czars in Russia", I'd like Ikiwiki to create "Czars\_in\_Russia.m > There's a simple patch that can do this: -> --- a/IkiWiki.pm -> +++ b/IkiWiki.pm -> @@ -584,7 +584,7 @@ sub htmllink ($$$;@) { -> return "<span class=\"createlink\"><a href=\"". -> cgiurl( -> do => "create", -> - page => pagetitle(lc($link), 1), -> + page => pagetitle($link, 1), -> from => $lpage -> ). -> "\">?</a>$linktext</span>" +<pre> +-- a/IkiWiki.pm ++++ b/IkiWiki.pm +@@ -584,7 +584,7 @@ sub htmllink ($$$;@) { + return "<span class=\"createlink\"><a href=\"". + cgiurl( + do => "create", +- page => pagetitle(lc($link), 1), ++ page => pagetitle($link, 1), + from => $lpage + ). + "\">?</a>$linktext</span>" +</pre> > This is fine if you don't mind mixed or randomly cased filenames getting > created. Otoh, if the link happened to start a sentence and so had its diff --git a/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn new file mode 100644 index 000000000..415e6af91 --- /dev/null +++ b/doc/bugs/backlinks_onhover_thing_can_go_weird.mdwn @@ -0,0 +1,43 @@ +I was just hovering over the '...' next to the backlinks on a page on +<http://ikiwiki.info/>. In terms of the size of my browser window, this was +towards the bottom-right of the screen. + +When I hovered over the '...', the additional backlinks float appeared. This +caused the page length to grow down, meaning a horizontal scrollbar was added +to the page. This meant the text reflowed, and the '...' moved outside of my +mouse pointer region. + +This caused an infinite loop of box appears... text moves, box disappears... +box re-appears.. which was not very visually pleasant. + +In general I think that the onhover float is a bit of bad UI. Even a truncated +list of backlinks looks cluttered due to there being no delimiters. I moved to +having an always-complete list of backlinks and having them as LI elements +inside a UL to make it look neater, although I appreciate that would make some +pages very long indeed. + +How about doing something a little like [[plugins/toggle]] for the excess +items instead? + +-- [[Jon]] + +---- + +An additional, related issue: if the box expands beyond the bottom of the +page, you might move your mouse pointer to the scrollbar in order to move +further down the list, but of course then you are outside the hover region. + +-- [[Jon]] + +> I agree, browser handling of this CSS is often not good. +> +> A toggle would be the perfect UI, but the heaviness of needing +> to include 30 lines of javascript to do it, plus then it only working +> with javascript enabled, is also not optimal. +> +> Another idea would be to make the "..." a link to the ikiwiki cgi. +> The cgi could then have a mode that displays all the backlinks of a page +> in a list. +> +> Yet another idea: Find some more refined CSS for handling a variable +> size popup.. --[[Joey]] diff --git a/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn b/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn new file mode 100644 index 000000000..320eca626 --- /dev/null +++ b/doc/bugs/edit_preview_resolves_links_differently_from_commit.mdwn @@ -0,0 +1,23 @@ +I'm editing /posts/foo. If I create a link to a subpage (in my case, +"discussion"), and hit preview, it gets resolved to /discussion, not +/posts/foo/discussion. If I hit commit, the latter happens. This seems like +a bug. --liw + +> That would be a bug, but I cannot reproduce it. For example, I edited +> <http://kitenet.net/~joey/blog/entry/wikis_out_of_disk/> and added a +> discussion link and on preview it went to the page's discussion page. I +> don't normally have a toplevel /discussion page, but I also tried adding +> one, and the link still doesn't link to it. Testcase? --[[Joey]] + +>> I can reproduce this on <http://blog.liw.fi/posts/distributed-internet-witness-service/>: +>> if I edit the page, then preview (no changes made), the "discussion" link at the bottom +>> of the page points in the preview +>> to <http://blog.liw.fi/discussion/>, +>> whereas the saved page has it pointing to +>> <http://blog.liw.fi/posts/distributed-internet-witness-service/discussion/>. +>> I'll arrange so that you can edit the page to test this. +>> --liw + +>> Joey suggested my wiki might be missing the FORCEBASEURL snippet from the misc.tmpl +>> template, and he's right. Mea culpa: I had not diffed the various templates when upgrading +>> and had missed that updated. [[done]] --liw diff --git a/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn new file mode 100644 index 000000000..5bab283fd --- /dev/null +++ b/doc/bugs/external_links_inside_headings_don__39__t_work.mdwn @@ -0,0 +1,24 @@ +The standalone 'markdown' utility is perfectly happy with an external link inside a `<h1>`, e.g.: + + # Review of [Dwarf Fortress][] + ... + [Dwarf Fortress]: http://www.bay12games.com/dwarves/ + +produces + + <h1>Review of <a href="http://www.bay12games.com/dwarves/">Dwarf Fortress</a></h1> + +but when I try to use this construct in an ikiwiki page, I get + + <h1>Review of [Dwarf Fortress][]</h1> + +It works fine with h2 and deeper. The square brackets also appear in the output of an [[ikiwiki/directive/inline]] directive in archive mode, I haven't tried non-archive mode. + +> I think you were confused by markdown's slightly wacky mix of square brackets and parens. +> The url in a markdown link goes in parens, not square brackets. For example: + +# [Google](http://google.com/) + +> [[done]] --[[Joey]] + +>> It works here but it definitely does *not* work on my wiki; but on further experimentation, I believe my problem is being caused by JasonBlevins' [h1title](http://code.jblevins.org/ikiwiki/plugins.git/plain/h1title.pm) plugin. diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn index 41f955e51..09ded91da 100644 --- a/doc/bugs/html5_support.mdwn +++ b/doc/bugs/html5_support.mdwn @@ -1,47 +1,44 @@ -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_. +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/). -> 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]] +* [HTML5 branch](http://git.webconverger.org/?p=ikiwiki;h=refs/heads/html5) +* [ikiwiki instance with HTML5 templates](http://natalian.org) -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. +# HTML5 Validation and t/html.t -* [Initial patch](http://git.webconverger.org/?p=ikiwiki;a=commit;h=2e2bb3f74f5000b1269142d6f9bdf1bcb4075ca4) +[validator.nu](http://validator.nu/) is the authorative 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. -> 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` +In the future, hopefully ikiwiki can test for valid HTML5 using [Relax NG +schema](http://syntax.whattf.org/) using a Debian package tool +[rnv](http://packages.qa.debian.org/r/rnv.html). -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. +# HTML5 migration issues -> Don't run ¨make test" ... --[[Joey]] ->> I don't quite grok debhelper7 [rules](http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/rules). +# [article](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-article-element) element ->>> Well, ok :-) `rm t/html.t` or, add an empty `override_dh_auto_test` rule. ->>> --[[Joey]] +This element is poorly supported by browsers. As a workaround, `style.css` needs: -[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. + article { + display: block; + } -# Notes +Internet Explorer will display it as a block, though you can't seem to be further control the style. -* 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]] +# Validator complains with no h1-h6 in header -* 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]] +* [#509](http://bugzilla.validator.nu/show_bug.cgi?id=509) + +## Time element + +The [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set by a template variable with what [HTML5 defines as a valid datetime string](http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string). + +As a workaround: + + au:~% grep timeformat natalian.setup + timeformat => '%Y-%m-%d', 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 new file mode 100644 index 000000000..85c2d0c6c --- /dev/null +++ b/doc/bugs/no_easy_way_to_wrap_HTML_container_around_a_set_of_inlined_pages.mdwn @@ -0,0 +1,9 @@ +The [[ikiwiki/directive/inline]] directive applies a template to each page-to-be-inlined, but the loop over the pages is in the Perl, not the template itself. This means if I want to wrap a container `<div>` or a `<table>` or whatever around the entire set of inlined pages, I can't do it by just editing the template. In fact, I think the only way to do it without hacking any Perl is with a wrapper template directive, e.g. + + \[[!template id="wrapinline" pages="..."]] + +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. diff --git a/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn b/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn new file mode 100644 index 000000000..dee1e9891 --- /dev/null +++ b/doc/bugs/pagespec_can__39__t_match___123__curly__125___braces.mdwn @@ -0,0 +1,44 @@ +I want match pages which have actually curly braces in the names (like this one), but this matches a lot of pages without the braces in their names :( : + +[[!inline show="3" feeds="no" archive="yes" pages="*_{*}_*"]] + +(note: the inline above has been restricted to 3 matches to keep this page +concise. Hopefully it is still clear that this page is not in the output set, +and the 3 pages in the output set do not contain curly braces in their +titles). + +When escaped, it doesn't work at all: + +[[!inline show="3" feeds="no" archive="yes" pages="*_\{*}_*"]] + +[[!inline show="3" feeds="no" archive="yes" pages="*_{*\}_*"]] + +More tests: + +"\*{\*": + +[[!inline show="3" feeds="no" archive="yes" pages="*{*"]] + +"\*\\{\*": + +[[!inline show="3" feeds="no" archive="yes" pages="*\{*"]] + +> This is due to the current handling of quoting and escaping issues +> when converting a pagespec to perl code. `safequote` is used to +> safely quote an input string as a `q{}` quote, and it strips +> curlies when doing so to avoid one being used to break out of the `q{}`. +> +> Alternative ways to handle it would be: +> +> * Escape curlies. But then you have to deal with backslashes +> in the user's input as they could try to defeat your escaping. +> Gets tricky. +> +> * Avoid exposing user input to interpolation as a string. One +> way that comes to mind is to have a local string lookup hash, +> and insert each user specified string into it, then use the hash +> to lookup the specified strings at runtime. [[done]] +> +> --[[Joey]] + +Thank you! I'll try it. --Ivan Z. 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 4a83f9ec8..c54376aa1 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -231,3 +231,44 @@ So, looking at your meta branch: --[[Joey]] >> handling, since po contains a workaround for that, and it's probably >> acceptable to use potentially slow methods to handle this case.) >> --[[Joey]] + +>>> I'm glad to implement whatever decision we'll make, but I don't +>>> clearly understand what this discussion's conclusion is. It seems +>>> like we agree at least on one point: meta page titles shall not be +>>> displayed all over the place by default; I have therefore disabled +>>> `meta_overrides_page_title` by default in my `meta` branch. +>>> +>>> My next question is then: do we only want to satisfy the `po` +>>> plugin needs? Or do we want to allow people who want this, such as +>>> [[madduck]], to turn on a config switch so that meta page titles +>>> are displayed as wikilinks titles? In the latter case, what level +>>> of configurability do we want? I can think of a quite inelegant +>>> way to implement full configurability, and provide a configuration +>>> switch for every place where links are displayed, such as +>>> wikilinks, parentlinks, etc., but I don't think the added bonus is +>>> worth the complexity of it. +>>> +>>> I think we can roughly split the needs into three categories: +>>> +>>> 1. never display any modified page title in links; this is the +>>> current behaviour, and we should keep it as the default one +>>> 2. display modified page titles only at well chosen places; that +>>> could be "manual" wikilinks, I mean those generated by the +>>> `link`, `camelcase` & al. plugins, the recentchanges page, and +>>> maybe a few other places; keep the usual pagename-based title +>>> for every other link, such as the parentlinks ones. +>>> The inter-page dependency problem remains, though. As a first +>>> step, I'm in favour of the "slow, but correct" implementation, +>>> with a big warning stating that enabling this option can make +>>> a wiki really sluggish; if someone really wants this to work +>>> fast, he/she'll implement a clever dependency handler :) +>>> 3. display modified page titles all over the place; IMHO, we +>>> should implement only the bits needed so that the `po` plugin +>>> can set this up, rather than provide this as +>>> a user-configurable option. +>>> +>>> So my question is: do we want to implement the #2 case, or not? +>>> I propose myself to only implement #1 and #3 to start with, but do +>>> it in a way that leaves room for #2. +>>> +>>> --[[intrigeri]] diff --git a/doc/bugs/pipe-symbol_in_taglink_target.mdwn b/doc/bugs/pipe-symbol_in_taglink_target.mdwn new file mode 100644 index 000000000..e467959be --- /dev/null +++ b/doc/bugs/pipe-symbol_in_taglink_target.mdwn @@ -0,0 +1,25 @@ +[[!tag bugs wishlist]] + +Escaping pipe-symbol in [[taglink|ikwiki/directive/taglink]] targets doesn't work as I wanted: + +[[!taglink smth_with_a_pipe|about_the_\|-symbol]] +[[!taglink smth_with_a_pipe|about_the_|-symbol]] + +as opposed to simple wikilinks: + +[[a link to smth with a pipe|about the \|-symbol]] +[[a link to smth with a pipe|about the |-symbol]] + +And it seems to work in pagespecs: + +tagged: + +[[!map pages="tagged(about the |-symbol)"]] + +[[!map pages="tagged(about the \|-symbol)"]] + +link: + +[[!map pages="link(about the |-symbol)"]] + +[[!map pages="link(about the \|-symbol)"]] diff --git a/doc/bugs/remove_plugin_and_untracked_files.mdwn b/doc/bugs/remove_plugin_and_untracked_files.mdwn new file mode 100644 index 000000000..07408c3bc --- /dev/null +++ b/doc/bugs/remove_plugin_and_untracked_files.mdwn @@ -0,0 +1,6 @@ +The [[plugins/remove]] plugin does not report an error if git rm fails. (It +probably doesn't if other VCS backends fail too). This can happen for example +if a page in your source directory is not a tracked file for whatever reason +(in my case, due to renaming the files and forgetting to commit that change). + + -- [[Jon]] diff --git a/doc/bugs/tagged__40____41___matching_wikilinks.mdwn b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn new file mode 100644 index 000000000..1bd556f50 --- /dev/null +++ b/doc/bugs/tagged__40____41___matching_wikilinks.mdwn @@ -0,0 +1,17 @@ +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. + +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 +contains information about an open issue with GDB. Then, I have a page +`/tag/open_issues_gdb.mdwn` that essentially contains `\[[!map +pages="tagged(open_issue_gdb)"]]`. So far, so good: this page indeed does list +all pages that are tagged like this. But now, when I add in `/gdb.mdwn` a link +to this page, like `\[[Open Issues|tag/open_issue_gdb]]`, then `/gdb.mdwn` +itself shows up in the map on `tag/open_issues_gdb.mdwn`. In my understanding +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]] |