diff options
Diffstat (limited to 'doc/bugs')
11 files changed, 355 insertions, 1 deletions
diff --git a/doc/bugs/External_link:_underscore_conversion.mdwn b/doc/bugs/External_link:_underscore_conversion.mdwn new file mode 100644 index 000000000..e99a70680 --- /dev/null +++ b/doc/bugs/External_link:_underscore_conversion.mdwn @@ -0,0 +1,21 @@ +Hi, + +found one strange thing here: + +If i enter a link like this + + [#Wikipedia:Mollison]: <http://www.tagari.com/bills_journal> + +the underscore appears like this (i inserted a space in the undercore-string to make it 'visible'): + + <a href="http://www.tagari.com/billsb14a7b8059d9c05 5954c92674ce60032journal">http://www.tagari.com/billsb14a7b8059d9c05 5954c92674ce60032journal</a> + +Am i doing something wrong? + +Thanks for your support and best wishes, +Tobias. + +> I believe you're hitting some kind of Markdown-processing but (so not +> strictly Ikiwiki related). Could you provide a minimal page source +> exhibiting the problem, and mention the exact nature of the processor +> you use? (Markdown, MultiMarkdown, pandoc, ...) --GB diff --git a/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn b/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn index 0cbef403d..bc934d109 100644 --- a/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn +++ b/doc/bugs/HTML_for_parentlinks_makes_theming_hard.mdwn @@ -39,7 +39,7 @@ I understand the logic behind doing this (on the front page it is the title as w I'll just modify the templates for my own site but I thought I'd report it as a bug in the hopes that it will be useful to others. Cheers, -Adam. +[[AdamShand]]. ---- > I just noticed that it's also different on the comments, preferences and edit pages. I'll come up with a diff and see what you guys think. -- Adam. diff --git a/doc/bugs/Pages_with_non-ascii_characters_like_öäå_in_name_not_found_directly_after_commit.mdwn b/doc/bugs/Pages_with_non-ascii_characters_like_öäå_in_name_not_found_directly_after_commit.mdwn new file mode 100644 index 000000000..8fb09f9d6 --- /dev/null +++ b/doc/bugs/Pages_with_non-ascii_characters_like_öäå_in_name_not_found_directly_after_commit.mdwn @@ -0,0 +1,145 @@ +At least my setup on kapsi.fi always prints 404 Not Found after adding a page with non-ascii characters in name. But the page exists and is visible after the 404 with url encoding and the blog page is inlined correctly on the feed page. + +Apparently ikiwiki.info does not complain with 404. Should the character encoding be set in wiki config? + +Happens also after editing the page. Here's an example: + + * page name displayed in 404: http://mcfrisk.kapsi.fi/skiing/posts/Iso-Sy%F6te%20Freeride%202011%20Teaser.html?updated + * page name in the blog feed: http://mcfrisk.kapsi.fi/skiing/posts/Iso-Sy%C3%B6te%20Freeride%202011%20Teaser.html + +Difference is in the word Iso-Syöte. Pehaps also the browsers is part of +the game, I use Iceweasel from Debian unstable with default settings. + +> I remember seeing this problem twice before, and both times it was caused +> by a bug in the *web server* configuration. I think at least one case it was +> due to an apache rewrite rule that did a redirect and mangled the correct +> encoding. +> +> I recommend you check there. If you cannot find the problem with your web +> server, I recommend you get a http protocol dump while saving the page, +> and post it here for analysis. You could use tcpdump, or one of the +> browser plugins that allows examining the http protocol. --[[Joey]] + +Server runs Debian 5.0.8 but I don't have access to the Apache configs. Here's the tcp stream from wireshark without cookie data, page name is testiä.html. I guess page name is in utf-8 but in redirect after post it is given to browser with 8859-1. + + POST /ikiwiki.cgi HTTP/1.1 + Host: mcfrisk.kapsi.fi + User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16) + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-us,en;q=0.5 + Accept-Encoding: gzip,deflate + Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 + Keep-Alive: 300 + Connection: keep-alive + Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi + Cookie: XXXX + Content-Type: multipart/form-data; boundary=---------------------------138059850619952014921977844406 + Content-Length: 1456 + + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="_submitted" + + 2 + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="do" + + edit + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="sid" + + 93c956725705aa0bbdff98e57efb28f4 + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="from" + + + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="rcsinfo" + + 5419fbf402e685643ca965d577dff3dafdd0fde9 + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="page" + + testi.. + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="type" + + mdwn + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="editcontent" + + test + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="editmessage" + + + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="_submit" + + Save Page + -----------------------------138059850619952014921977844406 + Content-Disposition: form-data; name="attachment"; filename="" + Content-Type: application/octet-stream + + + -----------------------------138059850619952014921977844406-- + HTTP/1.1 302 Found + Date: Wed, 02 Feb 2011 19:45:49 GMT + Server: Apache/2.2 + Location: /testi%E4.html?updated + Content-Length: 0 + Keep-Alive: timeout=5, max=500 + Connection: Keep-Alive + Content-Type: text/plain + + GET /testi%E4.html?updated HTTP/1.1 + Host: mcfrisk.kapsi.fi + User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16) + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-us,en;q=0.5 + Accept-Encoding: gzip,deflate + Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 + Keep-Alive: 300 + Connection: keep-alive + Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi + Cookie: XXXX + + HTTP/1.1 404 Not Found + Date: Wed, 02 Feb 2011 19:45:55 GMT + Server: Apache/2.2 + Content-Length: 279 + Keep-Alive: timeout=5, max=499 + Connection: Keep-Alive + Content-Type: text/html; charset=iso-8859-1 + + <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> + <html><head> + <title>404 Not Found</title> + </head><body> + <h1>Not Found</h1> + <p>The requested URL /testi..html was not found on this server.</p> + <hr> + <address>Apache/2.2 Server at mcfrisk.kapsi.fi Port 80</address> + </body></html> + +Getting the pages has worked every time: + + GET /testi%C3%A4.html HTTP/1.1 + Host: mcfrisk.kapsi.fi + User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16) + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 + Accept-Language: en-us,en;q=0.5 + Accept-Encoding: gzip,deflate + Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 + Keep-Alive: 300 + Connection: keep-alive + Cookie: XXXX + If-Modified-Since: Wed, 02 Feb 2011 19:45:54 GMT + If-None-Match: "1b518d-7c0-49b51e5a55c5f" + Cache-Control: max-age=0 + + HTTP/1.1 304 Not Modified + Date: Wed, 02 Feb 2011 20:01:43 GMT + Server: Apache/2.2 + Connection: Keep-Alive + Keep-Alive: timeout=5, max=500 + ETag: "1b518d-7c0-49b51e5a55c5f" diff --git a/doc/bugs/both_inline_and_comment_create_elements_id__61__feedlink.mdwn b/doc/bugs/both_inline_and_comment_create_elements_id__61__feedlink.mdwn new file mode 100644 index 000000000..170f3810e --- /dev/null +++ b/doc/bugs/both_inline_and_comment_create_elements_id__61__feedlink.mdwn @@ -0,0 +1,15 @@ +The [[plugins/inline]] and [[plugins/comments]] plugins both generate feed links. + +In both cases, the generated markup include an element with `id="feedlink"`. + +[XHTML 1.0 Strict](http://www.w3.org/TR/xhtml1/#h-4.10) (Ikiwiki's default output type) forbids multiple elements with the same ID: + +> In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above. See the HTML Compatibility Guidelines for information on ensuring such anchors are backward compatible when serving XHTML documents as media type text/html. + +As does [W3C's HTML5](http://www.w3.org/TR/html5/elements.html#the-id-attribute). + +Any page with both a comments feed and an inline feed will be invalid XHTML 1.0 Strict or HTML 5. + +-- [[Jon]] + +> [[news/version_3.2011012]] suggests this is fixed for `inline`, at least, I will test to see if it is cleared up for comments too. -- [[Jon]] diff --git a/doc/bugs/creating_page_from_comment_creates_a_comment.mdwn b/doc/bugs/creating_page_from_comment_creates_a_comment.mdwn new file mode 100644 index 000000000..0eff756de --- /dev/null +++ b/doc/bugs/creating_page_from_comment_creates_a_comment.mdwn @@ -0,0 +1,9 @@ +If a comment contains a WikiLink, for a page that doesn't exist, and the +user clicks on the edit link, and creates the page, it will itself be saved +as a comment, with "._comment" extension. + +This is very surprising and wrong behavior. The page editor tries to +preserve the linking page's format type, but it shouldn't do so if the page +is an internal page. --[[Joey]] + +[[done]] --[[Joey]] diff --git a/doc/bugs/default__95__pageext_not_working.mdwn b/doc/bugs/default__95__pageext_not_working.mdwn index c34491cf5..b7064206f 100644 --- a/doc/bugs/default__95__pageext_not_working.mdwn +++ b/doc/bugs/default__95__pageext_not_working.mdwn @@ -5,3 +5,12 @@ I tried to set it as 'txt' and as a custom plugin I am developing but when I edi Yes I am only trying to set it to loaded and working plugins. ikiwiki version 3.20101129 + +> I've tested `default_pageext` with 3.20110124, and it works fine. +> +> It seems to me from what you describe that you expect +> it to have an effect when you go and edit an existing page. +> That's not what it's for, it only chooses the default used +> when creating a new page. +> +> Closing this bug as apparent user error. --[[Joey]] [[done]] diff --git a/doc/bugs/enumerations_of_dates_not_formatted_correctly.mdwn b/doc/bugs/enumerations_of_dates_not_formatted_correctly.mdwn new file mode 100644 index 000000000..263ddd78b --- /dev/null +++ b/doc/bugs/enumerations_of_dates_not_formatted_correctly.mdwn @@ -0,0 +1,43 @@ +When an enumeration contains entries starting with ordinal numbers, e.g., for lists of meeting dates, ikiwiki turns them all into the 1st. + +Testcase: + +*The following lists should read: 1. January, 27. March, 99. November, 42. April* +**But instead it reads:** + +* 1. January +* 27. March +* 99. November +* 42. April + +> That's a consequence of Markdown syntax. The syntax for ordered lists +> (HTML `<ol>`) in Markdown is to use arbitrary numeric prefixes in that style, +> so your text gets parsed as: +> +> <ul> +> <li> +> <ol> +> <li>January</li> +> </ol> +> </li> +> ... +> +> You can avoid that interpretation by escaping the dot with a backslash +> (`1\. January`) like so: +> +> * 1\. January +> * 27\. March +> +> or by writing "1st January" and so on. --[[smcv]] + +>> I think that this is a bug in Text::Markdown (and probably other +>> versions of markdown). The [markdown spec)(http://daringfireball.net/projects/markdown/syntax.text), +>> though unmaintained and bitrotted into near illegibility, seems to say +>> that list items can only be preceeded by whitespace: +>> +>>> "List markers typically start at the left margin, but may be indented by +>>> up to three spaces." +>> +>> So "* * * 1. 2. 3." should not be parsed as a deeply nested list. +>> +>> Forwarded to [upsteam RT](https://rt.cpan.org/Ticket/Display.html?id=65116). [[done]] --[[Joey]] diff --git a/doc/bugs/maps_with_nested_directories_sometimes_make_ugly_lists.mdwn b/doc/bugs/maps_with_nested_directories_sometimes_make_ugly_lists.mdwn new file mode 100644 index 000000000..f66e2c0e5 --- /dev/null +++ b/doc/bugs/maps_with_nested_directories_sometimes_make_ugly_lists.mdwn @@ -0,0 +1,60 @@ +I'm using the [[map_directive|ikiwiki/directive/map]] to build dynamic navigation menus, and it's working really nicely! + +However on some pages, each nested item each get wrapped in a full set of `<ul>` tags. This doesn't actually hurt anything, but it's does it inconsistently which seems like a bug. I don't like it because it puts extra vertical spacing into my menu bar. + +Here's what I expect it to look like: + + <div class="map"> + <ul> + <li><span class="selflink">Archives</span> + <ul> + <li><a href="./2010/" class="mapitem">2010</a></li> + <li><a href="./2011/" class="mapitem">2011</a></li> + </ul> + </li> + </ul> + </div> + +And here's what it's actually doing: + + <div class="map"> + <ul> + <li><span class="selflink">Archives</span> + <ul> + <li><a href="./2010/" class="mapitem">2010</a></li> + </ul> + <ul> + <li><a href="./2011/" class="mapitem">2011</a></li> + </ul> + </li> + </ul> + </div> + +I've tried to replicate the problem on this site and cannot, I'm not sure if that's because of exactly how I'm using map or if there's something different with my site. I just upgraded ikiwiki to the latest Debian unstable as well as most of the required Perl modules and nothing changed. + +If you look at [this page on my site](http://adam.shand.net/ikidev/archives/) (getsource is enabled) you can see it working as expected in the main page and not working in the side bar. + +But it also doesn't work on the sitemap page: <http://adam.shand.net/ikidev/site/map/> + +This might be really simple, but I've been staring at it too long and it only looks like a bug to me. :-( Any suggestions would be gratefully accepted. -- [[AdamShand]] + +> Okay, I think I've figured this out, it looks like ikiwiki behaves differently depending on the level of heirarchy. I'll post the details once I'm sure. -- [[AdamShand]] + +>> I managed to replicate the issue on my ikiwiki, and I believe it is a +>> bug. The current upstream logic for going up/down by a level opens +>> (and closes) the unnecessary lists that you are seeing. Although the +>> resulting markup is semantically correct, it has superflous stuff +>> that introduces whitespace issues at the very least. + +>> I have a [[patch]] up [on my git repo](http://git.oblomov.eu/ikiwiki/patch/55fa11e8a5fb351f9371533c758d8bd3eb9de245) +>> that ought to fix the issue. + +>>> Wonderful, thank you very much for the help! I've installed the patch and it's working great, but it looks like there a minor bug. Sometimes it doesn't print the top/first map item. Cheers, -- [[AdamShand]] +>>> +>>> <http://adam.shand.net/tmp/map-orig.jpg> +>>> <http://adam.shand.net/tmp/map-patched.jpg> + +>>>> Thanks for testing. I managed to reproduce it and I adjusted the logic. +>>>> An updated [[patch]] can be found [here](http://git.oblomov.eu/ikiwiki/patch/dcfb18b7989a9912ed9489f5ff15f871b6d8c24a) + +>>>>> Seems to work perfectly to me, thanks! -- [[AdamShand]] diff --git a/doc/bugs/no_search_button__44___hence_can__39__t_do_search_in_w3m_at_ikiwiki.info.mdwn b/doc/bugs/no_search_button__44___hence_can__39__t_do_search_in_w3m_at_ikiwiki.info.mdwn new file mode 100644 index 000000000..2d600fdbb --- /dev/null +++ b/doc/bugs/no_search_button__44___hence_can__39__t_do_search_in_w3m_at_ikiwiki.info.mdwn @@ -0,0 +1,32 @@ +If I browse <http://ikiwiki.info> in [emacs-w3m](http://www.emacswiki.org/emacs/emacs-w3m) (without Javascript), I +can't do a [[search|plugins/search]]: the text field is there (so I can +enter my search request), but there seems to be no way to make +actually a search request (i.e., no button). + +(A remark on how it works now in the other browsers: +In the more "complete" +browsers (Chromium etc.), the request is done by pressing Enter in the +text field.) +--Ivan Z. + +I see, no Javascript is probably involved in using the search form; +the code is simply: + + <form method="get" action="/ikiwiki.cgi" id="searchform"> + <div> + <input type="text" id="searchbox" name="P" value="" size="16" + /> + </div> + </form> + +So, if the semantics suggested by HTML is such that such a form is to +be submitted by some default form submitting action in the UI and it +doesn't really require a button to be functional, then I'd say it's +not an ikiwiki's problem, but a missing feature in the UI of emacs-w3m +or the underlying w3m... Perhaps I'll report this issue to them. --Ivan Z. + +[[!tag done]] +There is no problem at all! +I'm sorry for this hassle! +In emacs-w3m, there is the <code>w3m-submit-form</code> command +(<kbd>C-c C-c</kbd>) to submit the form at point; it works.--Ivan Z. diff --git a/doc/bugs/po:_might_not_add_translated_versions_of_all_underlays.mdwn b/doc/bugs/po:_might_not_add_translated_versions_of_all_underlays.mdwn new file mode 100644 index 000000000..82aed400d --- /dev/null +++ b/doc/bugs/po:_might_not_add_translated_versions_of_all_underlays.mdwn @@ -0,0 +1,16 @@ +[[plugins/po]]'s `checkconfig` looks in the `underlaydirs`, but plugins that +add underlays typically do so in their own `checkconfig`. + +As far as I can see, this will result in it not adding translated versions +of underlays added by a plugin that comes after it in `$config{add_plugins}`; +for instance, if you have `add_plugins => qw(po smiley)`, you'll probably +not get the translated versions of `smileys.mdwn`. (I haven't tested this.) + +> It doesn't happen because smiley adds the underlay unconditionally on +> import. Which is really more usual. + +To see them all, `po` should use `last => 1` when registering the hook. +--[[smcv]] + +> At least all that don't last their hooks too! But, added, since +> it will make the problem much less likely to occur. --[[Joey]] [[done]] diff --git a/doc/bugs/preview_base_url_should_be_absolute.mdwn b/doc/bugs/preview_base_url_should_be_absolute.mdwn index f865f03ae..f160a84c4 100644 --- a/doc/bugs/preview_base_url_should_be_absolute.mdwn +++ b/doc/bugs/preview_base_url_should_be_absolute.mdwn @@ -47,3 +47,7 @@ So, I'm seriously thinking about reverting the part of [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]] that made `baseurl(undef)` relative. And I suppose, re-opening that todo. :( --[[Joey]] + +---- + +This was fixed in version 3.20110105 [[done]] --[[Joey]] |