diff options
Diffstat (limited to 'doc/bugs')
-rw-r--r-- | doc/bugs/CGI_edit_and_slash_in_page_title.mdwn | 18 | ||||
-rw-r--r-- | doc/bugs/git_fails_to_compile.mdwn | 30 | ||||
-rw-r--r-- | doc/bugs/ikiwiki_is_not_truly_localizable.mdwn | 38 | ||||
-rw-r--r-- | doc/bugs/recentchanges_feed_links.mdwn | 6 |
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 |