summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/Pages_with_non-ascii_characters_like_öäå_in_name_not_found_directly_after_commit.mdwn10
-rw-r--r--doc/bugs/enumerations_of_dates_not_formatted_correctly.mdwn11
-rw-r--r--doc/bugs/no_search_button__44___hence_can__39__t_do_search_in_w3m_at_ikiwiki.info.mdwn32
-rw-r--r--doc/bugs/po:_might_not_add_translated_versions_of_all_underlays.mdwn10
4 files changed, 63 insertions, 0 deletions
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..e7cb43bee
--- /dev/null
+++ b/doc/bugs/Pages_with_non-ascii_characters_like_öäå_in_name_not_found_directly_after_commit.mdwn
@@ -0,0 +1,10 @@
+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.
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..4a78ea3f9
--- /dev/null
+++ b/doc/bugs/enumerations_of_dates_not_formatted_correctly.mdwn
@@ -0,0 +1,11 @@
+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
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..66d16bf23
--- /dev/null
+++ b/doc/bugs/po:_might_not_add_translated_versions_of_all_underlays.mdwn
@@ -0,0 +1,10 @@
+[[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.)
+
+To see them all, `po` should use `last => 1` when registering the hook.
+--[[smcv]]