summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2009-03-08 09:50:27 +0100
committerintrigeri <intrigeri@boum.org>2009-03-08 09:50:27 +0100
commitae474d8e14631ff519ed7d54bb64eaa0538f56d9 (patch)
tree09637db5faf2632b67b581cf04463fe4493584d4 /doc/bugs
parent0314ed459ba1c49fad9170a54cc05f1c9e9c96bf (diff)
parent08e4472fc469c630ebef93e16a66a5a69d9cb33a (diff)
Merge commit 'upstream/master' into prv/po
Conflicts: IkiWiki/Plugin/editpage.pm debian/control debian/copyright doc/todo/need_global_renamepage_hook.mdwn Signed-off-by: intrigeri <intrigeri@boum.org>
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn22
-rw-r--r--doc/bugs/INC_location_not_set_correctly_in_make_test.mdwn24
-rw-r--r--doc/bugs/PNG_triggers_UTF-8_error_in_MimeInfo.pm.mdwn25
-rw-r--r--doc/bugs/bzr_plugin_does_not_define_rcs__95__diff.mdwn27
-rw-r--r--doc/bugs/cannot_reliably_use_meta_in_template.mdwn4
-rw-r--r--doc/bugs/html5_support.mdwn47
-rw-r--r--doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn219
-rw-r--r--doc/bugs/remove_orphaned_sparkline-php_from_Suggests.mdwn20
-rw-r--r--doc/bugs/shortcut_plugin_will_not_work_without_shortcuts.mdwn.mdwn33
-rw-r--r--doc/bugs/support_for_openid2_logins.mdwn10
-rw-r--r--doc/bugs/tags__44___backlinks_and_3.x.mdwn34
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]]