diff options
Diffstat (limited to 'doc/bugs')
| -rw-r--r-- | doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn | 22 | ||||
| -rw-r--r-- | doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn | 24 | ||||
| -rw-r--r-- | doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn | 25 | ||||
| -rw-r--r-- | doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn | 27 | ||||
| -rw-r--r-- | doc/bugs/cannot_reliably_use_meta_in_template.mdwn | 4 | ||||
| -rw-r--r-- | doc/bugs/html5_support.mdwn | 47 | ||||
| -rw-r--r-- | doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn | 219 | ||||
| -rw-r--r-- | doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn | 20 | ||||
| -rw-r--r-- | doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn | 33 | ||||
| -rw-r--r-- | doc/bugs/support_for_openid2_logins.mdwn | 10 | ||||
| -rw-r--r-- | doc/bugs/tags__44___backlinks_and_3.x.mdwn | 34 |
11 files changed, 463 insertions, 2 deletions
diff --git a/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn new file mode 100644 index 000000000..fbdc58d5d --- /dev/null +++ b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn @@ -0,0 +1,22 @@ +The Atom feed from <http://planet.collabora.co.uk/> +get "double-encoded" (UTF-8 is decoded as Latin-1 and re-encoded as +UTF-8) when aggregated with IkiWiki on Debian unstable. The RSS 1.0 +and RSS 2.0 feeds from the same Planet are fine. All three files +are in fact correct UTF-8, but IkiWiki mis-parses the Atom. + +This turns out to be a bug in XML::Feed, or (depending on your point +of view) XML::Feed failing to work around a design flaw in XML::Atom. +When parsing RSS it returns Unicode strings, but when parsing Atom +it delegates to XML::Atom's behaviour, which by default is to strip +the UTF8 flag from strings that it outputs; as a result, they're +interpreted by IkiWiki as byte sequences corresponding to the UTF-8 +encoding. IkiWiki then treats these as if they were Latin-1 and +encodes them into UTF-8 for output. + +I've filed a bug against XML::Feed on CPAN requesting that it sets +the right magical variable to change this behaviour. IkiWiki can +also apply the same workaround (and doing so should be harmless even +when XML::Feed is fixed); please consider merging my 'atom' branch, +which does so. --[[smcv]] + +[[!tag patch done]] diff --git a/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn b/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn new file mode 100644 index 000000000..1d396c85b --- /dev/null +++ b/doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn @@ -0,0 +1,24 @@ +'make test' has the following errors: + +Can't locate Locale/gettext.pm in @INC (@INC contains: /home/turian/utils//lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /home/turian/utils//lib/perl5/site_perl/5.8.8 . /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8) at (eval 254) line 2. + +What's weird is that I already have gettext.pm: + /home/turian/utils/lib/perl5/lib/i386-linux-thread-multi/Locale/gettext.pm + +That directory should be part of @INC, because I have: + export PERL5LIB="$PERL5LIB:$UTILS/lib/perl5/lib/i386-linux-thread-multi/" +in my .bashrc. However, /home/turian/utils/lib/perl5/lib/i386-linux-thread-multi/ does not appear in that @INC line. + +How do I get the proper @INC locations set? + +> Nothing in ikiwiki touches whatever PERL5DIR setting you may have, +> so AFAICS, this must be some sort of local configuration problem. +> How do +> `/home/turian/utils//lib/perl5/site_perl/5.8.8/i386-linux-thread-multi` +> and `/home/turian/utils//lib/perl5/site_perl/5.8.8` get into the +> displayed `@INC`? The likely way seems to be that something in your +> system sets PERL5LIB to contain those directories, clobbering +> the earlier setting in your `.bashrc`. +> --[[Joey]] + +[[!tag done]] diff --git a/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn b/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn new file mode 100644 index 000000000..0a1299993 --- /dev/null +++ b/doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn @@ -0,0 +1,25 @@ +If a PNG image matches the [[ikiwiki/PageSpec]] of an [[ikiwiki/directive/inline]] directive, the page throws the following error: + +> \[[!inline Error: Malformed UTF-8 character (fatal) at /usr/local/lib/perl5/site_perl/5.8.8/File/MimeInfo.pm line 120.]] + +Individual posts display fine, and moving the offending image outside the scope of the [[ikiwiki/directive/inline]] directive's PageSpec eliminates the error. + +> I tried to reproduce this with a random png and File::MimeInfo +> version 0.15, but could not. The png was included in the generated feed +> via an enclosure, as it should be; no warnings or errors. +> +> Looking at the source to File::MimeInfo and its changelog, +> I'm pretty sure that this problem was fixed in version +> 0.14: +>> - Fixed bug with malformed utf8 chars in default() method +> +> The code involved in that fix looks like this: +> +>> no warnings; # warnings can be thrown when input not ascii +>> if ($] < 5.008 or ! utf8::valid($line)) { +>> use bytes; # avoid invalid utf8 chars +> +> I guess that your locally installed version of File::MimeInfo is older than +> this. So closing this bug [[done]]. If you still see the problem with a current +> version of File::MimeInfo, please reopen and include where I can get a png file +> that triggers the problem. --[[Joey]] diff --git a/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn b/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn new file mode 100644 index 000000000..0294ec62e --- /dev/null +++ b/doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn @@ -0,0 +1,27 @@ +The bzr plugin does not seem to define the rcs_diff subroutine. +I got the follow error after enabling recentchangesdiff: + +"Undefined subroutine &IkiWiki::Plugin::bzr::rcs_diff called at /usr/share/perl5/IkiWiki.pm line 1590." + +Grepping to verify absence of rcs_diff: + + $ grep rcs_diff /usr/share/perl5/IkiWiki/Plugin/{git,bzr}.pm + /usr/share/perl5/IkiWiki/Plugin/git.pm: hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff); + /usr/share/perl5/IkiWiki/Plugin/git.pm:sub rcs_diff ($) { + /usr/share/perl5/IkiWiki/Plugin/bzr.pm: hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff); + +> I've added the minimal stub needed to avoid the crash, but for +> recentchangesdiff to work, someone needs to implement `rcs_diff` for bzr. +> This should be trivial if you know and use bzr. The function +> is passed as a parameter the revno of interest and just needs +> to ask bzr for the diff between that and the previous version. --[[Joey]] + +>> I'll see if I can make a patch. The bzr command to get the revision would +>> look like this: bzr diff -r revno:$PREV:/path/to/src..revno:$REVNO:/path/to/src +>> (where $PREV would be $REVNO minus one). --liw + +>> Sorry, that was not entirely correct, for some reason. I'll add a patch below that +>> seems to work. I am unfortunately not ready to set up a git repository that you +>> can pull from. --liw + +[[done]] --[[Joey]] diff --git a/doc/bugs/cannot_reliably_use_meta_in_template.mdwn b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn index 046f40a7e..de6c227f6 100644 --- a/doc/bugs/cannot_reliably_use_meta_in_template.mdwn +++ b/doc/bugs/cannot_reliably_use_meta_in_template.mdwn @@ -4,6 +4,8 @@ pass, which does not look at the template a page includes, it will not be seen then, and so other pages that use the page title probably won't use it. (Barring luck with build order.) +Update: This also affects using tags from templates. + There is a simple fix for this, just add `scan => 1` when registering the preprocess hook for the template plugin. @@ -12,3 +14,5 @@ scan pass, every page containing a template will cause the template to be loaded and filled out. This can be some serious additional overhead. --[[Joey]] + +[[done]] diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn new file mode 100644 index 000000000..41f955e51 --- /dev/null +++ b/doc/bugs/html5_support.mdwn @@ -0,0 +1,47 @@ +Some elements of [HTML5](http://www.whatwg.org/specs/web-apps/current-work/multipage/) can be safely supported by ikiwiki. There are [several differences between HTML4 and HTMl5](http://www.w3.org/TR/html5-diff/). Unsupported new elements _should degrade gracefully_. + +> In the `origin/html` branch, there is an old work in progress to make +> ikiwiki use html 4 instead of xhtml. If that could be brought forward and +> finished then the plan has been to switch ikiwiki over to doing html 4. +> I don't think it makes sense to try to make it support both xhtml and +> html, it would complicate the code for no benefit. +> +> I think that is the best route toward supporting html 5 as well. Get +> ikiwiki doing html 4 first and the changes needed to get to 5 from there +> should be small. Probably just changing some doctypes and a few other +> small changes which could be kept in a branch, or even shipped in ikiwiki +> mainline as an alternate set of templates. Some of the changes, like +> supporting new html 5 tags in the htmlscrubber, can be done in mainline. +> (Like was already done for the html 5 video and audio tags.) +> +> This approach seems much more maintainable going foward than rolling a +> html 5 branch immediatly and trying to keep that continually up-to-date +> with mainline ikiwiki that is still using xhtml. --[[Joey]] + +However as an [early adopter](http://en.wikipedia.org/wiki/Early_adopter) I would like to start using HTML5 as much as possible. The more pragmatic solution would be to use elements supported by the browsers of your readership I guess. I'm following other early adopters like [Anne](http://annevankesteren.nl/) for clues on how to proceed. + +* [Initial patch](http://git.webconverger.org/?p=ikiwiki;a=commit;h=2e2bb3f74f5000b1269142d6f9bdf1bcb4075ca4) + +> I can't figure out how to pull from this repository. +>> Sorry! I have fixed the cloneurl file to read `git clone git://webconverger.org/git/ikiwiki` + +I'm unsure how to turn off the test validation by the very old [wdg-html-validator](http://packages.qa.debian.org/w/wdg-html-validator.html). So I have been unable to test my initial patches as I can't build ikiwiki. I would like to know how to edit the rules/Makefile to temporarily disable this. + +> Don't run ¨make test" ... --[[Joey]] +>> I don't quite grok debhelper7 [rules](http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/rules). + +>>> Well, ok :-) `rm t/html.t` or, add an empty `override_dh_auto_test` rule. +>>> --[[Joey]] + +[validator.nu](http://validator.nu/) incidentally is **the** HTML5 validator, however it is almost impossible to sanely introduce as a build dependency because of its insane Java requirements. :( I test locally via [cURL](http://wiki.whatwg.org/wiki/IDE), though Debian packages cannot be built with a network dependency. + +# Notes + +* the [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set with iso8601 time +* I suspect the migration to the new semantic elements of HTML5 like article, header & footer to take some time, due to browser support. Though they sure make the template code look much nicer. +* `<br>` and too many `<div>`s usually indicates poor semantics. + > YMMV, but I tend to find that kind of concern counterproductive. + > --[[Joey]] + +* Many of the header `<span>`s should be proper [header elements](http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements) + > See [[todo/Option_to_make_title_an_h1__63__]] for why not. --[[Joey]] 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 cccd53d05..4a83f9ec8 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -2,8 +2,127 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title --[[madduck]] -> Agreed. [[todo/using_meta_titles_for_parentlinks]] contains a beginning of -> solution. A few quick notes about it: +---- + +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. + +<ul> +<li> I give pagetitle the full path to a page. +<li> I redefine the 'pagetitle'-sub to deal with it. +<li> to maintain compatibility for IkiWikis without the meta-plugin, i added a 'basename' to the Original-pagetitle. +</ul> + +<pre> +diff -c /usr/share/perl5/IkiWiki/Render.pm.distrib /usr/share/perl5/IkiWiki/Render.pm +*** /usr/share/perl5/IkiWiki/Render.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Render.pm Tue Aug 26 23:29:32 2008 +*************** +*** 102,108 **** + $template->param( + title => $page eq 'index' + ? $config{wikiname} +! : pagetitle(basename($page)), + wikiname => $config{wikiname}, + content => $content, + backlinks => $backlinks, +--- 102,108 ---- + $template->param( + title => $page eq 'index' + ? $config{wikiname} +! : pagetitle($page), + wikiname => $config{wikiname}, + content => $content, + backlinks => $backlinks, + +diff -c /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm.distrib /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm +*** /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Plugin/parentlinks.pm Tue Aug 26 23:19:43 2008 +*************** +*** 44,50 **** + "height_$height" => 1, + }; + $path.="/".$dir; +! $title=IkiWiki::pagetitle($dir); + $i++; + } + return @ret; +--- 44,50 ---- + "height_$height" => 1, + }; + $path.="/".$dir; +! $title=IkiWiki::pagetitle($path); + $i++; + } + return @ret; + +diff -c /usr/share/perl5/IkiWiki.pm.distrib /usr/share/perl5/IkiWiki.pm +*** /usr/share/perl5/IkiWiki.pm.distrib Wed Aug 6 07:48:34 2008 +--- /usr/share/perl5/IkiWiki.pm Tue Aug 26 23:47:30 2008 +*************** +*** 792,797 **** +--- 792,799 ---- + my $page=shift; + my $unescaped=shift; + ++ $page=basename($page); ++ + if ($unescaped) { + $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : chr($2)/eg; + } + +diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki/Plugin/meta.pm +*** /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib Wed Aug 6 07:34:55 2008 +--- /usr/share/perl5/IkiWiki/Plugin/meta.pm Tue Aug 26 23:30:58 2008 +*************** +*** 3,8 **** +--- 3,9 ---- + package IkiWiki::Plugin::meta; + + use warnings; ++ no warnings 'redefine'; + use strict; + use IkiWiki 2.00; + +*************** +*** 289,294 **** +--- 290,319 ---- + } + } + ++ sub IkiWiki::pagetitle ($;$) { ++ my $page=shift; ++ my $unescaped=shift; ++ ++ if ($page =~ m#/#) { ++ $page =~ s#^/##; ++ $page =~ s#/index$##; ++ if ($pagestate{"$page/index"}{meta}{title}) { ++ $page = $pagestate{"$page/index"}{meta}{title}; ++ } else { ++ $page = IkiWiki::basename($page); ++ } ++ } ++ ++ if ($unescaped) { ++ $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : chr($2)/eg; ++ } ++ else { ++ $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : "&#$2;"/eg; ++ } ++ ++ return $page; ++ } ++ + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + +</pre> + +---- + +> A few quick notes about it: > - Using <code>inline</code> would avoid the redefinition + code duplication. > - A few plugins would need to be upgraded. @@ -16,3 +135,99 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title >> Thus tagging [[patch]]. --[[intrigeri]] >> >>> Joey, please consider merging my `meta` branch. --[[intrigeri]] + +So, looking at your meta branch: --[[Joey]] + +* Inter-page dependencies. If page A links to page B, and page B currently + has no title, then A will display the link as "B". Now page B is modified + and a title is added. Nothing updates "A". + The added overhead of rebuilding every page that links to B when B is + changed (as the `postscan` hook of the po plugin does) is IMHO a killer. + That could be hundreds or thousands of pages, making interactive editing + way slow. This is probably the main reason I had not attempted this whole + thing myself. IMHO this calls for some kind of intellegent dependency + handler that can detect when B's title has changed and only rebuild pages + that link to B in that case. +* Looks like some plugins that use `pagetitle` to format it for display + were not changed to use `nicepagetitle` (for example, rename). + But most of those callers intend to display the page name + as a title, but including the parent directories in the path. (Ie, + "renaming foo/page title to bar/page title" -- + you want to know it's moved from foo to bar.) `nicepagetitle` does not + allow doing that since it always takes the `basename`. +* I don't like the name `nicepagetitle`. It's not very descriptive, is it? + And it seems very confusing to choose whether to use the "nice" or original + version. My hope is that adding a second function is unnecessary. + As I understand it, you added a new function for two reasons: + 1) It needs the full page name, not basename. + 2) `titlepage(pagetitle($page))` reversability. + + 1) If you look at all the callers + Of `pagetitle` most of them pass a complete page name, not just the + basename. In most cases `pagetitle` is used to display the full name + of the page, including any subdirectory it's in. So why not just make + it consitently be given the full name of the page, with another argument + specifying if we want to get back just the base name. + + 2) I can't find any code that actually uses the reversability like that. + The value passed to `titlepage` always comes from some external + source. Unless I missed one. +* The use of `File::Spec->rel2abs` is a bit scary. +* Does it really make sense to call `pagetitle` on the meta title + in meta's `nicepagetitle`? What if the meta title is something like + "foo_bar" -- that would be changed to "foo bar". +* parentlinks is changed to use `nicepagetitle(bestlink($page, $path))`. + Won't `bestlink` return "" if the parent page in question does not exist? +* `backlinks()` is changed to add an additional `title` field + to the hash returned, but AFAICS this is not used in the template. +* Shouldn't `Render.pm` use nicepagetitle when getting the title for the + page template? Then meta would not need to override the title in the + `pagetemplate` hook. (Although this would eliminate handling of + `title_overridden` -- but that is little used and would not catch + all the other ways titles can be overridden with this patch anyway.) + +> I'm not a reviewer or anything, but can I chime in on changes to pagetitle? +> I don't think having meta-titles in wikilinks and the parentlinks path by +> default is necessarily a good thing. I don't consider the meta-title of a page +> as used in `<title>` to be the same thing as the short title you +> want in those contexts - IMO, the meta-title is the "formal" title of the page, +> enough to identify it with no other context, and frequently too long to be used +> as a link title or a parentlink, whereas the parentlinks title in particular +> should be some abbreviated form that's enough to identify it in context. +> [tbm](http://www.cyrius.com/) expressed a similar opinion when I was discussing +> ikiwiki with him at the weekend. +> +> It's a matter of taste whether wikilinks are "like a parentlink" or "like a +> `<title>`"; I could be persuaded either way on that one. +> +> An example from my site: [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/) +> is the parent of [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/wifi/) +> with a title too long to use in the latter's parentlinks; I think the titles of +> both those pages are too long to use as wikilink text too. Similarly, tbm's page +> about [Debian on Orion devices from Buffalo](http://www.cyrius.com/debian/orion/buffalo/) +> can simply be called "Buffalo" in context. +> +> Having a `\[[!meta abbrev="..."]]` that took precedence over title +> in parentlinks and possibly wikilinks might be a good way to fix this? Or if your +> preference goes the other way, perhaps a `\[[!meta longtitle=""]]` could take +> precedence when generating the `<title>` and the title that comes after the +> parentlinks. --[[smcv]] + +>> I think you've convinced me. (I had always had some doubt in my mind as +>> to whether using titles in all these other places would make sense.) +>> +>> Instead of meta abbrev, you could have a meta pagename that +>> overrides the page name displayed everywhere (in turn overridden by +>> meta title iff the page's title is being displayed). But is this complexity +>> needed? We have meta redir, so if you want to change the name of a page, +>> you can just rename it, and put in a stub redirection page so links +>> still work. +>> +>> This leaves the [[plugins/contrib/po]] plugin, which really does need +>> a way to change the displayed page name everywhere, and at least a +>> subset of the changes in the meta branch are needed to support that. +>> +>> (This would also get around my concern about inter-page dependency +>> handling, since po contains a workaround for that, and it's probably +>> acceptable to use potentially slow methods to handle this case.) +>> --[[Joey]] diff --git a/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn new file mode 100644 index 000000000..b4e2a1501 --- /dev/null +++ b/doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn @@ -0,0 +1,20 @@ +Hi! + +How about to replace sparkline-php from Suggests by a better alternative? + +I would like to file a RM bug to get it out of archive. Do you have a better alternative for it? PHP has a lot of them.. + +Thanks + +> sparline-php is orphaned *in Debian*. Upstream, is has seen activity as +> recently as 11 months ago. +> +> I don't know of a better alternative. I looked at the perl sparkline +> stuff in CPAN and is was bad enough that the pain of using php from this +> perl program was a better alternative. +> +> Anyway, it works great; maintaining the sparkline-php package in Debian +> would certianly be much less work than finding some alternative and +> rewriting the ikiwiki code to use it, *and* packaging that alternative +> and maintaining it in Debian. So your suggestion doesn't make a lot of +> sense; Debian should just find a maintainer for sparkline-php. --[[Joey]] diff --git a/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn b/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn new file mode 100644 index 000000000..5cc669106 --- /dev/null +++ b/doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn @@ -0,0 +1,33 @@ +On my initial ikiwiki -setup auto.setup, I get the following error: + + shortcut plugin will not work without shortcuts.mdwn + /home/turian/utils/etc/ikiwiki/auto.setup: ikiwiki --refresh --setup /home/turian/iki.setup failed at IkiWiki/Setup/Automator.pm line 105. + + +This is using the latest git pull of ikiwiki. +I am not sure why it is not finding shortcuts.mdwn. -- [[JosephTurian]] + +> The error, and the weird paths suggest to me that you +> have installed ikiwiki in a strange way, and it is failing +> to find its basewiki underlay. The `$installdir` is +> hardcoded into IkiWiki.pm at build time, based on the PREFIX +> setting (see README). +> +> If that's not set right, you'll have other problems than just this one, +> so I suggest you check how you installed ikiwiki. +> +> Anyway, I've made the shortcut plugin only warn about this.. +> --[[Joey]] + +> > I have +> > $installdir="/home/turian/utils/" +> > and the underlay dir is set to: +> > "$installdir/share/ikiwiki/basewiki", +> > which does contain shortcuts.mdwn. So I am not sure why it is not finding it. +> > I am grappling with installing ikiwiki in a user account, and would like to get the directories set up correctly. +> > How can I debug this issue further? + +>>>> Why don't you strace it and look at where it's looking for +>>>> shortcuts.mdwn. --[[Joey]] + +>>>>>> Hmm, so change the PERL5LIB seemed to fix this. [[Done]]. diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn new file mode 100644 index 000000000..f78d50c3c --- /dev/null +++ b/doc/bugs/support_for_openid2_logins.mdwn @@ -0,0 +1,10 @@ +I have several complaints that users cannot contribute to my ikiwiki instances since they only have OpenID logins that support OpenID2. E.g. Yahoo!'s OpenID only supports 2.0+ + +This is not the fault of ikiwiki, though the problem lies within the [perl openid consumer](http://packages.qa.debian.org/libn/libnet-openid-consumer-perl.html) in Debian which is a 1.x implementation AFAIK. + +I've contacted JanRain who have pointed me to: + +* [OpenID4Perl](http://code.sxip.com/openid4perl/) +* Some [work](http://code.sixapart.com/svn/openid/trunk/perl/) by David Recordon + +However both Perl OpenID 2.x implementations have not been released and are incomplete implementations. :( diff --git a/doc/bugs/tags__44___backlinks_and_3.x.mdwn b/doc/bugs/tags__44___backlinks_and_3.x.mdwn new file mode 100644 index 000000000..4fe9a4723 --- /dev/null +++ b/doc/bugs/tags__44___backlinks_and_3.x.mdwn @@ -0,0 +1,34 @@ +I think there might be an issue in the backlinks calculation in ikiwiki 3.04. + +I've just migrated to 3.04. In doing so, the following pagespec + +> "log/* and !link(tag/aggregation) and !link(tag/draft) and !*/Discussion" + +...started matching pages which contained + +> \[\[!template draft\]\] + +The page templates/draft.mdwn contains (amongst some markup) + +> \[\[!tag draft \]\] + +Prior to migration, the pagespec definitely took effect post-transclusion. + +An example: <http://jmtd.net/log/too_much_debconf_a_bad_thing/> contains the +template inclusion, which can be seen to have worked due to markup at the +bottom of the page. It even includes a "Tags: draft" link at the bottom. + +Strangely, <http://jmtd.net/tag/draft/> does not contain backlinks to pages +which are tagged using the procedure above. + +After the first rebuild, it's broken, after a subsequent refresh, it is fixed. +I've reproduced this twice (but assumed I'd done something wrong the first +time, so went ahead and migrated live, spamming planet debian in the process +:(). I will try and put together a testcase. -- [[users/Jon]], 2009/02/17 + +> Looks like the same problem as +> [[cannot_reliably_use_meta_in_template]]. AFAIK, this has never worked +> reliably, although the linked page has a simple, though potentially +> expensive fix. --[[Joey]] + +> fix made, [[done]] --[[Joey]] |