summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/CGI_edit_and_slash_in_page_title.mdwn18
-rw-r--r--doc/bugs/git_fails_to_compile.mdwn30
-rw-r--r--doc/bugs/ikiwiki_is_not_truly_localizable.mdwn38
-rw-r--r--doc/bugs/recentchanges_feed_links.mdwn6
4 files changed, 92 insertions, 0 deletions
diff --git a/doc/bugs/CGI_edit_and_slash_in_page_title.mdwn b/doc/bugs/CGI_edit_and_slash_in_page_title.mdwn
new file mode 100644
index 000000000..ec5763924
--- /dev/null
+++ b/doc/bugs/CGI_edit_and_slash_in_page_title.mdwn
@@ -0,0 +1,18 @@
+Try clicking the Edit link for <http://ikiwiki.info/todo/Add_showdown_GUI_input__47__edit/>
+
+The link produces a query string that the edit CGI interprets to
+mean `edit.mdwn` in an `Add showdown GUI input` subpage.
+
+There's something there now, but only because I created it. When
+I first tried it, it came up blank. I tried several different ways
+of altering the escaping of the query string to get the real page to
+come up, but I never succeeded, so I just grabbed the original text
+from git and pasted it into the new page....
+
+So somehow the generation of Edit links and the CGI for doing the
+editing need to get in agreement on just how they're going to
+escape slashes in a page title.
+
+--Chapman Flack
+
+> bleh. [[Fixed|done]] --[[joey]]
diff --git a/doc/bugs/git_fails_to_compile.mdwn b/doc/bugs/git_fails_to_compile.mdwn
new file mode 100644
index 000000000..fdd1df533
--- /dev/null
+++ b/doc/bugs/git_fails_to_compile.mdwn
@@ -0,0 +1,30 @@
+Background: I'm running ikiwiki on OS X leopard, (a laptop), and I have the wiki running locally, as it's mostly for note taking and personal stuff. Anyway.
+
+I'd been using svn, but I'm making the leap to git (finally) and moving the wiki over as well...
+
+The git works great, I am in fact, quite pleased. Here's the problem. When I try and run `ikiwiki --setup [setupfile]` I get the following message:
+
+ Can't exec "git": No such file or directory at /opt/local/lib/perl5/vendor_perl/5.8.8/IkiWiki/Rcs/git.pm line 29.
+ /Users/tychoish/.ikiwiki/ikiwiki.setup: Cannot exec 'git log --max-count=50 --pretty=raw --raw --abbrev=40 --always -c -r HEAD -- .': No such file or directory
+ BEGIN failed--compilation aborted at (eval 6) line 139.
+
+ /Users/$HOME/.ikiwiki/ikiwiki.setup: 'git log --max-count=50 --pretty=raw --raw --abbrev=40 --always -c -r HEAD -- .' failed:
+ BEGIN failed--compilation aborted at (eval 6) line 139.
+
+---
+
+I can get the wiki to compile if: I take the git stuff out of the setup file, if I put `rcs => ""` **or** if I set the the git_master_branch to "".
+
+I think the problem is that ikiwiki can't deal with the onslaught of such a large quantity of history/log information at once, somehow, because the repository came to this moment with a lot of history that the compiler has to crunch through. How to remedy this, is beyond my skill insight...
+
+Thanks.
+
+-- [[tychoish]]
+
+> It looks like it can't find git; what is $PATH set to when ikiwiki is run, and is git in one of those directories? --[[bma]]
+>> Yeah, ikiwiki and git are both installed underneath macports, which is in the path and works just fine most of the time, and I use macports stuff a lot.
+
+>>> The PATH is set at the top of the ikiwiki program; so the system's PATH
+>>> setting, or one in the environment will be ignored. (This is done for
+>>> security since ikiwiki can be run setuid.) If you need to use
+>>> a nonstandard path, you'll need to edit that. --[[Joey]]
diff --git a/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn b/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn
new file mode 100644
index 000000000..11bf1cab5
--- /dev/null
+++ b/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn
@@ -0,0 +1,38 @@
+A lot of strings in ikiwiki are hardcoded and not taken for locales resources through gettext. This is bad because ikiwiki is thus difficult to spread for non-english users.
+
+I mean that, for instance in CGI.pm, line like:
+
+`my @buttons=("Save Page", "Preview", "Cancel");`
+
+should be written as
+
+`my @buttons=(gettext("Save Page"), gettext("Preview"), gettext("Cancel"));`
+
+> Yes, these need to be fixed. But note that the localised texts come back
+> into ikiwiki and are used in various places, including plugins.
+> Including, possibly, third-party plugins. So localising the buttons would
+> seem to require converting from the translations back into the C locale
+> when the form is posted. --[[Joey]]
+
+In standards templates things seems wrongly written too. For instance in page.tmpl line like:
+
+`<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>`
+
+should be written as
+
+`<li><a href="<TMPL_VAR EDITURL>" rel="nofollow"><TMPL_VAR EDITURL_TEXT</a></li>`
+
+with EDITURL_TEXT variable initialized in Render.pm through a gettext call.
+
+Am I wrong ?
+
+> No, that's not a sane way to localise the templates. The templates can be
+> translated by making a copy and modifying it, or by using a tool to
+> generate .mo files from the templates, and generate translated templates
+> from .po files. (See [[todo/l10n]] for one attempt.) But pushing the
+> localisation of random strings in the templates through the ikiwiki
+> program defeats the purpose of having templates at all. --[[Joey]]
+
+If not I can spend some time preparing patches for such corrections if it can help.
+
+-- [[/users/bbb]]
diff --git a/doc/bugs/recentchanges_feed_links.mdwn b/doc/bugs/recentchanges_feed_links.mdwn
index 32073415f..eb543587c 100644
--- a/doc/bugs/recentchanges_feed_links.mdwn
+++ b/doc/bugs/recentchanges_feed_links.mdwn
@@ -26,3 +26,9 @@ to turn on? --Chapman Flack
>>> "recentchanges#someid" will probably work. Probably first by addressing the
>>> todo about [[todo/ability_to_force_particular_UUIDs_on_blog_posts]],
>>> and then by just using that new ability in the page. --[[Joey]]
+
+>>>> Ah. The prerequisite todo looks like more than I'd like to take on.
+>>>> In the meantime, would it be very involved to change whatever bug now
+>>>> optimizes away the change pages, or to simply have all the links in the
+>>>> feed point to the recentchanges page itself, with no fragment id?
+>>>> Either would be a bit nicer than having broken links in the feed. --Chap