diff options
Diffstat (limited to 'doc/bugs')
11 files changed, 246 insertions, 3 deletions
diff --git a/doc/bugs/CGI_problem_with_some_webservers.mdwn b/doc/bugs/CGI_problem_with_some_webservers.mdwn index a40a454c1..e4b0fd448 100644 --- a/doc/bugs/CGI_problem_with_some_webservers.mdwn +++ b/doc/bugs/CGI_problem_with_some_webservers.mdwn @@ -67,3 +67,42 @@ Why do they appear two times with conflicting values in the very same hashes? >>>> (reported as [[!debbug 437927]] and [[!debbug 437932]]) --[[JeremieKoenig]] Marking [[done]] since it's not really an ikiwiki bug. --[[Joey]] + +---- + +I'm using boa and getting some odd behaviour if I don't set the `umask` +option in the config file. Editing a page through the web interface and +hitting "Save Page" regenerates the `index.html` file with no world-read +permissions. As a result, the server serves a "403 - Forbidden" error page +instead of the page I was expecting to return to. + +There are only two ways I found to work around this: adding a `umask 022` +option to the config file, or re-compiling the wiki from the command line +using `ikiwiki --setup`. Setting up a git back-end and re-running `ikiwiki +--setup` from inside a hook had no effect; it needed to be at the terminal. +--Paul + +> Since others seem to have gotten ikiwiki working with boa, +> I'm guessing that this is not a generic problem with boa, but that +> your boa was started from a shell that had an unusual umask and inherited +> that. --[[Joey]] + +>> That's right; once I'd worked out what was wrong, it was clear that any +>> webserver should have been refusing to serve the page. I agree about the +>> inherited umask; I hadn't expected that. Even if it's unusual, though, it +>> probably won't be uncommon - this was a stock Ubuntu 9.04 install. --Paul + +(I'm new to wiki etiquette - would it be more polite to leave these details +on the wiki, or to remove them and only leave a short summary? Thanks. +--Paul) + +> Well, I just try to keep things understandable and clear, whether than +> means deleting bad old data or not. That said, this page is a bug report, +> that was already closed. It's generally better to open a new bug report +> rather than edit an old closed one. --[[Joey]] + +>> Thanks for the feedback, I've tidied up my comment accordingly. I see +>> your point about the bug; sorry for cluttering the page up. I doubt it's +>> worth opening a new page at this stage, but will do so if there's a next +>> time. The solution seems worth leaving, though, in case anyone else in my +>> situation picks it up. --Paul diff --git a/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn b/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn index 0fccd1dcb..7559e6d0a 100644 --- a/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn +++ b/doc/bugs/Filenames_with_colons_cause_problems_for_Windows_users.mdwn @@ -68,3 +68,8 @@ Windows does not support filenames containing any of these characters: `/ \ * : >>> ikiwiki on windows, including its assumption that the directory >>> separator is "/". Windows will be supported when someone sends me a >>> comprehansive and not ugly or performance impacting patch. :-) --[[Joey]] + +> Speaking of Windows filename problems, how do I keep directories ending in a +> period from being created? The following didn't seem to work. +> `wiki_file_chars => "-[:alnum:]+/._",` +> `wiki_file_regex => '[-[:alnum:]+_]$',` diff --git a/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn b/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn new file mode 100644 index 000000000..1a737df0a --- /dev/null +++ b/doc/bugs/Renaming_a_file_via_the_web_is_failing_when_using_subversion.mdwn @@ -0,0 +1,28 @@ +I'm using ikiwiki 3.12 on Mac OS X (installed via mac ports) + +When trying to rename a file via the web interface (using the rename plugin) I get the following error: + +Error: Undefined subroutine &IkiWiki::Plugin::svn::dirname called at /opt/local/lib/perl5/vendor_perl/5.8.9/IkiWiki/Plugin/svn.pm line 246. + +Applying the following patch fixed it: + + --- IkiWiki/Plugin/svn.pm.orig 2009-07-08 12:25:23.000000000 -0400 + +++ IkiWiki/Plugin/svn.pm 2009-07-08 12:28:36.000000000 -0400 + @@ -243,10 +243,10 @@ + + if (-d "$config{srcdir}/.svn") { + # Add parent directory for $dest + - my $parent=dirname($dest); + + my $parent=IkiWiki::dirname($dest); + if (! -d "$config{srcdir}/$parent/.svn") { + while (! -d "$config{srcdir}/$parent/.svn") { + - $parent=dirname($dest); + + $parent=Ikiwiki::dirname($dest); + } + if (system("svn", "add", "--quiet", "$config{srcdir}/$parent") != 0) { + warn("svn add $parent failed\n"); + + +> Thank you very much for the patch, which I've applied. I wonder how +> that snuck in (aside from the obvious, that the svn plugin is not often +> used and the code was added w/o being tested..). [[done]] --[[Joey]] diff --git a/doc/bugs/img_with_alt_has_extra_double_quote.mdwn b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn new file mode 100644 index 000000000..81bbe7fb5 --- /dev/null +++ b/doc/bugs/img_with_alt_has_extra_double_quote.mdwn @@ -0,0 +1,32 @@ +The [[ikiwiki/directive/img]] directive emits an extra double quote if alt=x is +specified (as is necessary for valid HTML). This results in malformed HTML, +like this: + + <img src="U" width="W" height="H"" alt="A" /> + ^ + +This [[patch]] is available from the img-bugfix branch in my git repository: + + commit a648c439f3467571374daf597e9b3a659ea2008f + Author: Simon McVittie <smcv@ http://smcv.pseudorandom.co.uk/> + Date: 2009-06-16 17:15:06 +0100 + + img plugin: do not emit a redundant double-quote before alt attribute + + diff --git a/IkiWiki/Plugin/img.pm b/IkiWiki/Plugin/img.pm + index a697fea..a186abd 100644 + --- a/IkiWiki/Plugin/img.pm + +++ b/IkiWiki/Plugin/img.pm + @@ -121,7 +121,7 @@ sub preprocess (@) { + my $imgtag='<img src="'.$imgurl. + '" width="'.$im->Get("width"). + '" height="'.$im->Get("height").'"'. + - (exists $params{alt} ? '" alt="'.$params{alt}.'"' : ''). + + (exists $params{alt} ? ' alt="'.$params{alt}.'"' : ''). + (exists $params{title} ? ' title="'.$params{title}.'"' : ''). + (exists $params{class} ? ' class="'.$params{class}.'"' : ''). + (exists $params{id} ? ' id="'.$params{id}.'"' : ''). + +--[[smcv]] + +[[done]] --[[Joey]] diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn new file mode 100644 index 000000000..ceedbbdaa --- /dev/null +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -0,0 +1,49 @@ +[[!tag plugins/map patch]] + +input: + + before. + \[[!map pages="sdfsdfsdfsd/*"]] + after. + +Presuming that the pagespec does not match, output: + + <p>before. + <div class="map"> + <ul> + </div></p> + +The UL element is not closed. + +Patch: + + --- /usr/share/perl5/IkiWiki/Plugin/map.pm 2009-05-06 00:56:55.000000000 +0100 + +++ IkiWiki/Plugin/map.pm 2009-06-15 12:23:54.000000000 +0100 + @@ -137,11 +137,11 @@ + $openli=1; + $parent=$item; + } + - while ($indent > 0) { + + while ($indent > 1) { + $indent--; + $map .= "</li>\n</ul>\n"; + } + - $map .= "</div>\n"; + + $map .= "</ul>\n</div>\n"; + return $map; + } + + +-- [[Jon]] + +> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either... +> could `map` instead delay emitting the first `<ul>` until it determines that +> it will have at least one item? Perhaps refactoring that function into +> something easier to regression-test would be useful. --[[smcv]] + +>> You are right (just checked 4.01 DTD to confirm). I suspect refactoring +>> the function would be wise. From my brief look at it to formulate the +>> above I thought it was a bit icky. I'm not a good judge of what would +>> be regression-test friendly but I might have a go at reworking it. With +>> this variety of problem I have a strong inclination to use HOFs like map, +>> grep. - [[Jon]] diff --git a/doc/bugs/nested_raw_included_inlines.mdwn b/doc/bugs/nested_raw_included_inlines.mdwn new file mode 100644 index 000000000..33433e235 --- /dev/null +++ b/doc/bugs/nested_raw_included_inlines.mdwn @@ -0,0 +1,34 @@ +I have the following structure: + +## page0 + # Page 0 + \[[!inline raw="yes" pages="page1"]] + +## page1 + # Page 1 + \[[!inline pages="page2"]] + +## page2 + # Page 2 + test + +In this situation, a change in page 2 will trigger a rebuild of page1 but not of page0. + + refreshing wiki.. + scanning page2.mdwn + rendering page2.mdwn + rendering page1.mdwn, which depends on page2 + done + +In my real world situation, page1 is actually listing all pages that match a certain tag and page0 is the home page. +Whenever a page got tagged, it will appear on page1 but not on page0. + +Am I missing something? Is this a bug or Ikiwiki not supposed to support this use case? + +> Perhaps the inline plugin isn't being clever enough about dependencies - +> strictly speaking, when a page is inlined with full content, the inlining +> page should probably inherit all the inlined page's dependencies. +> That might be prohibitively slow in practise due to the way IkiWiki +> currently merges pagespecs, though - maybe the patches I suggested for +> [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]] +> would help? --[[smcv]] diff --git a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn new file mode 100644 index 000000000..85a206bc0 --- /dev/null +++ b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn @@ -0,0 +1,17 @@ +The git commit (in my `openid` branch) says it all: + + Update IkiWiki::openiduser to work with Net::OpenID 2.x + + openiduser previously used a constructor that no longer works in 2.x. + However, all we actually want is the (undocumented) DisplayOfURL function + that is invoked by the display method, so try to use that. + +This bug affects ikiwiki.info (my commits show up in [[RecentChanges]] as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]). + +> Cherry picked, thanks. --[[Joey]] + +Relatedly, the other commit on the same branch would be nice to have +(edited to add: I've now moved it, and its discussion, to +[[todo/pretty-print_OpenIDs_even_if_not_enabled]]). --[[smcv]] + +[[!tag done]] 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 042d6a20c..be14e5126 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -1,3 +1,5 @@ +[[!tag patch plugins/inline patch/core]] + The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text. --[[madduck]] @@ -5,7 +7,7 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title ---- It is possible to set a Page-Title in the meta-plugin, but that one isn't -reused in parentlinks. This [[patch]] may fix it. +reused in parentlinks. This patch may fix it. <ul> <li> I give pagetitle the full path to a page. @@ -132,7 +134,7 @@ diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki > >> It was actually more complicated than expected. A working prototype is >> now in my `meta` branch, see my userpage for the up-to-date url. ->> Thus tagging [[patch]]. --[[intrigeri]] +>> Thus tagging patch. --[[intrigeri]] >> >>> Joey, please consider merging my `meta` branch. --[[intrigeri]] diff --git a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn new file mode 100644 index 000000000..430d65a3f --- /dev/null +++ b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn @@ -0,0 +1,32 @@ +Prettydate creates strings like this: _Last edited in the wee hours of Tuesday night, July 1st, 2009_. However, July 1st is a Wednesday, so either date or Weekday should be modified. In the spirit is probably _Tuesday night, June 30th_. --ulrik + +> The default prettydate times are fairly idiosyncratic to +> how [[Joey]] thinks about time. Specifically, it's still +> Tuesday night until he wakes up Wednesday morning -- which +> could be in the afternoon. :-P But, Joey also realizes +> that dates change despite his weird time sense, and so +> July 1st starts at midnight on Tuesday and continues +> through Tuesday night and part of Wednesday. +> +> (This might not be as idiosyncratic as I make it out to be.. +> I think that many people would agree that in the wee hours +> of New Years Eve, when they're staggering home ahead of +> the burning daylight, the date is already January 1st.) +> +> I think the bug here is that prettydate can't represent +> all views of time. While the times +> of day can be configured, and it's possible to configure it +> to call times after midnight "Wednesday morning, July 1st", +> it is not possible to configure the date or weekday based +> on the time of day. +> +> In order to do so, prettydate's timetable would need to be +> extended to include the "%B %o, %Y" part, and that extended +> to include "%B-", "%o-", and "%Y-" to refer to the day +> before. +> +> --[[Joey]] + +>> fair enough, I think I can get converted to a warped time perspective. --ulrik + +>>> Perhaps we can consider this [[done]], then? --[[smcv]] diff --git a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn index dace2ca19..08af5fe2c 100644 --- a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn +++ b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn @@ -11,7 +11,7 @@ It seems like gettext only searches for locale information in /usr/share/locale, return $gettext_obj->get(shift); } -[[!tag patch]] +[[!tag patch patch/core]] -- [[ThomasBleher]] > According to my testing, this patch makes ikiwiki's localisation fail for diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn index 1d99370f6..139a53760 100644 --- a/doc/bugs/support_for_openid2_logins.mdwn +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -15,3 +15,8 @@ However both Perl OpenID 2.x implementations have not been released and are inco > an OpenID 2 implementation (it's the second of the projects > above). I've filed a bug in Debian asking for the package to be > updated. --[[smcv]] + +> Net::OpenID::Consumer 1.x is now in Debian unstable --[[dom]] + +> I've tested with yahoo, and it works with the updated module. Sweet and +> [[done]] --[[Joey]] |