Merge tag '3.20120202' into trail3-integrated

32 files changed, 523 insertions, 17 deletions

diff --git a/doc/todo/Improve_markdown_speed.mdwn b/doc/todo/Improve_markdown_speed.mdwn
new file mode 100644
index 000000000..de3230c9e
--- /dev/null
+++ b/doc/todo/Improve_markdown_speed.mdwn
@@ -0,0 +1,33 @@
+I'm not sure where the bottleneck is for running ikiwiki over a site like
+my blog
+[Natalian](http://source.natalian-org.branchable.com/?p=source.git;),
+though I like to think the markdown processing could be speeded up by the
+support of the C implementation of Markdown called
+[Sundown](https://github.com/tanoku/sundown).
+
+>> Sundown doesn't appear to have Perl bindings, so the cost of calling a
+>> separate process could wipe out some or all of the speed gain.  It might
+>> be worth looking into Text::Upskirt instead, which uses the Upskirt
+>> library which Sundown appears to be derived from. -- [[KathrynAndersen]]
+
+>>> It would be fairly easy to write a perl binding for sundown. For that
+>>> matter, Text::Upskirt could be adapted to it. I am waiting for any of
+>>> upskirt, sundown and perl bindings to get into Debian, then I will 
+>>> see about making ikiwiki use them.
+>>> 
+>>> For now, I have added discount support to ikiwiki. This does speed up
+>>> markdown rendering by up to 40x, although when building a site ikiwiki
+>>> in practice does other work, so the gains are less impressive. Building
+>>> the ikiwiki doc wiki went from 62 to 45 seconds. The lack of a Debian 
+>>> package of Text::Markdown::Discount means this is not used by default
+>>> yet.
+>>> 
+>>> (Upskirt, discount... Who comes up with these names? Discount also 
+>>> features a "NOPANTS" option.) --[[Joey]]
+
+>>>> Thanks for doing this; it's given a well-needed speedup to my huge site.
+>>>>
+>>>> (At least "Discount" is related to "Mark Down" but I don't fathom "Upskirt" either.)
+>>>> --[[KathrynAndersen]]
+
+[[wishlist]]
diff --git a/doc/todo/Modern_standard_layout.mdwn b/doc/todo/Modern_standard_layout.mdwn
new file mode 100644
index 000000000..37f1ee740
--- /dev/null
+++ b/doc/todo/Modern_standard_layout.mdwn
@@ -0,0 +1,39 @@
+I think it would be a good idea to think about the standard layout style of ikiwiki, the current layout used in a standard setup and on ikiwiki.info as well looks a bit old-fashioned to me. I guess that a nice modern layout would attract more new ikiwiki users and boost the ikwiki community... 
+
+> FWIW, I agree.  The actiontabs [[theme|themes]] would be a better default, but something which showed what ikiwiki was capable of (or more precicely: that ikiwiki is as capable as other popular wiki softwares) would be better still. — [[Jon]]
+
+>> As an author of plugins that interact with the UI, I think it's good that
+>> a *minimal* ikiwiki has a minimal anti-theme, and that plugins are
+>> developed against the anti-theme - it's a "blank slate" for themes.
+>> [[plugins/contrib/trail]] was much easier to get working in
+>> the default anti-theme than in actiontabs and blueview.
+>>
+>> Technical detail: all the standard themes are done by appending to the
+>> anti-theme's CSS (albeit in ikiwiki's build system rather than during
+>> the wiki build), rather than by replacing it - so themes that haven't
+>> been updated for a new UI element end up using the version of it from
+>> the anti-theme. [[plugins/Comments]] and [[plugins/contrib/trail]]
+>> both need some tweaks per-theme to make them integrate nicely,
+>> but most of the design comes from the anti-theme.
+>>
+>> That doesn't necessarily mean the anti-theme should be the one used
+>> on ikiwiki.info, or used by default in new wikis - from my
+>> point of view, it'd be fine for either of those to be actiontabs
+>> or something The important thing is to *have* a "blank slate" anti-theme
+>> that looks simple but sufficient, as a basis for new styles (either
+>> [[themes]], or wikis that want their own unique stylesheet), and derive
+>> the other themes from it. --[[smcv]]
+
+> Ikiwiki's minimal theme is not modern. It's postmodern. I like it for the
+> reasons described here. <http://kitenet.net/~joey/blog/entry/web_minimalism/>
+> " The minimalism sucked you in, it made the web feel like one coherent,
+> unified thing, unlike the constellation of corporate edifices occupying
+> much of it today."
+> 
+> I see an increasing trend back toward these principles, driven partly
+> by limits of eg, smartphone UI. So I certianly won't be changing the
+> look of any of my ikiwiki sites, including this one.
+> 
+> `auto.setup` and `auto-blog.setup` could have different defaults,
+> or allow a theme to be picked as [Branchable](http://branchable.com/)
+> does. Perhaps actiontabs for auto-blog and default for wikis? --[[Joey]]
diff --git a/doc/todo/Pagination_next_prev_links.mdwn b/doc/todo/Pagination_next_prev_links.mdwn
index f1c12d33f..8474c9c27 100644
--- a/doc/todo/Pagination_next_prev_links.mdwn
+++ b/doc/todo/Pagination_next_prev_links.mdwn
@@ -4,12 +4,20 @@ They don't want to back out of post to an index. They want an easy button to cli
 
 <http://codex.wordpress.org/Next_and_Previous_Links>
 
-Thank you
+[Jekyll](http://jekyllrb.com/)'s implementation looks rather neat:
+
+* <https://github.com/mojombo/jekyll/wiki/template-data>
+* <https://github.com/mojombo/jekyll/blob/master/lib/jekyll/generators/pagination.rb>
+
+
 
 > This is a perfect use for [[todo/wikitrails]], of which my
 > [[plugins/contrib/trail]] plugin is an implementation. Code review on that
 > plugin would be welcome; it might even get merged one day.
 >
+>> The trail plugin is very likely to be merged soon, and is already
+>> available. So, closing this bug report [[done]] --[[Joey]]
+>
 > Unfortunately, IkiWiki blogs use a [[ikiwiki/PageSpec]] to define the set of
 > "posts" in the blog (through which the next/prev trail should range), and
 > the current implementation of [[plugins/contrib/trail]] in terms of typed
@@ -27,7 +35,34 @@ Thank you
 > reduces the generic usefulness of typed links, though - in particular
 > you can no longer use "is part of trail A" in a PageSpec. --[[smcv]]
 
+>> Version 3 of [[plugins/contrib/trail]] now does this. For `traillink`
+>> and `trailitem` it additionally adds a typed link, which it does not
+>> itself consume; for `trailinline` and `trail` it doesn't. --[[smcv]]
+
 >>> Indeed, I know the problem; I ran into the same kind of thing with my [[plugins/contrib/report]] plugin and its `trail` concept.
 >>> I simply had to declare that one couldn't use "trail" and "maketrail" options within the same report. That way, "maketrail" will add links in the "scan" pass, and "trail" will test for links in the "build" pass.  That usually works. --[[KathrynAndersen]]
 
+>>>> I'm not sure that even that is *quite* right: if your `trail` takes
+>>>> pagespecs as arguments, then it's potentially evaluating those pagespecs
+>>>> before all pages have been scanned, which could mean it lists pages
+>>>> which matched the spec before a recent change, or doesn't list pages
+>>>> which didn't previously match the spec but do now.
+>>>>
+>>>> In version 3 of [[plugins/contrib/trail]] I ended up storing
+>>>> uninterpreted pagespecs and links at scan time, and evaluating them the
+>>>> first time a page is built. I *think* that's sufficiently lazy to give
+>>>> the right answer... --[[smcv]]
+
 >> Do you have an example? --[[hendry]]
+
+>>> Now linked on the plugin's page - it doesn't pretend to be a blog, but
+>>> [the second demo](http://demo.hosted.pseudorandom.co.uk/trail2/)
+>>> is a `trailinline`, so you could do that with blog posts just as well.
+>>> Making [[plugins/contrib/album]] require `trail` v3, and trying it out
+>>> on my blog, are next on the list.
+>>> --[[smcv]]
+
+>>>> Sorry thank link <http://demo.hosted.pseudorandom.co.uk/trail2/> doesn't work. I get a forbidden. --[[hendry]]
+
+
+[[wishlist]]
diff --git a/doc/todo/Render_multiple_destinations_from_one_source.mdwn b/doc/todo/Render_multiple_destinations_from_one_source.mdwn
new file mode 100644
index 000000000..5fd787607
--- /dev/null
+++ b/doc/todo/Render_multiple_destinations_from_one_source.mdwn
@@ -0,0 +1,50 @@
+I've set up a couple of sites where the users use ikiwiki in fairly standard mode as a CMS and I then set up another ikiwiki setup file that's got the edit options turned off, but is pointing at the same git repository in the background.  I then make the post-update hook for each be <tt>post-update-hook.ikiwiki</tt> and <tt>post-update-hook.ikiwiki-public</tt> and have the <tt>post-update</tt> hook itself be a script like:
+
+    #!/bin/sh
+    
+    $0.ikiwiki "$@"
+    $0.ikiwiki-public "$@"
+
+obviously this results in duplication of most of the <tt>ikiwiki.setup</tt>, a spare working directory that (perhaps) isn't needed, and an extra post-update hook plus wrapper script that is really needless extra complication.
+
+If instead there was a way of specifying additional destdir's, or perhaps more generally a way of specifying that there should be multiple passes through the build process using alternative values for some of the variables, then one could have both the private wiki view, and the public static view generated with minimal additional configuration.
+
+One idea that occurs to me is an <tt>additional_configs</tt> list where one would specify files containing just the settings you want to override compared with the main setup file.
+
+Alternatively, one might invent a new way of specifying alternative settings.  i.e.:
+
+     additionalsites:
+       - public
+
+     destdir: /home/wiki/wiki-view
+     destdir[public]: /home/wiki/public_html
+
+     disable_plugins: []
+     disable_plugins[public]:
+       - recentchanges
+       - editpage
+
+     url: https://example.com/editors/
+     url[public]: http://www.example.com/
+
+     ...
+
+where the existance of the <tt>additionalsites</tt> list provokes additional runs through using the settings with matching extra bits to be used to override the defaults found in the rest of the file.
+
+Just brainstorming a bit after [[liw]]'s comment about this being useful on IRC, and thought I'd write the idea up while I was thinking about it. -[[fil]]
+
+> I don't think you can avoid ikiwiki needing to store a different
+> `.ikiwiki` directory with state for each site. Differences in
+> configuration can affect the state it stores in arbitrary ways,
+> ranging from which pages are even built to what plugins are enabled and
+> store state. This also means that it doesn't make sense to try and
+> share state amoung rebuilds of the same site.
+> 
+> There is a hidden, and undocumented configuration setting `wikistatedir`
+> that can actually be pointed at a different directory than `.ikiwiki`.
+> Then you can rebuild multiple configurations from one working directory.
+> 
+> Another handy trick is to use the old perl-format (not yaml) setup file,
+> and parameterize it using `$ENV{FOO}`, then you can build two different
+> setups from the same setup file.
+> --[[Joey]]
diff --git a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
index 4bc828e6e..e0074eef8 100644
--- a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
+++ b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
@@ -2,6 +2,8 @@
 
 Here's my next version of the patch - still a work in progress.
 
+  Note:I partially updated part of this patch to work on Ikiwiki v3 - see [here](http://ikiwiki.info/forum/Calendar:_listing_multiple_entries_per_day/) -- Matt Ford
+
 It provides the following new features. The features are designed to preserve the behavior of the existing plugin by default.
 
  * If you specify an event preprocessor in a post, such as:
diff --git a/doc/todo/Split_plugins_with_external_dependencies_into_separate_Debian_packages.mdwn b/doc/todo/Split_plugins_with_external_dependencies_into_separate_Debian_packages.mdwn
new file mode 100644
index 000000000..fdf0dea50
--- /dev/null
+++ b/doc/todo/Split_plugins_with_external_dependencies_into_separate_Debian_packages.mdwn
@@ -0,0 +1,40 @@
+The Debian ikiwiki package has a pile of recommends and suggests for packages needed by various plugins and other optional functionality.  To make it easier for people to figure out what to install, and to make it easier for automatic dependency tracking to remove packages ikiwiki no longer needs, we could split the plugins with additional dependencies into their own packages.
+
+Notable plugin dependencies:
+
+- [[plugins/img]] depends on [[!debpkg perlmagick]]
+- [[plugins/graphviz]] depends on [[!debpkg graphviz]]
+  - [[plugins/linkmap]] depends on the graphviz plugin, so it should probably go in the same package.
+- [[plugins/polygen]] depends on [[!debpkg polygen]]
+- [[plugins/teximg]] depends on [[!debpkg dvipng]] and [[!debpkg texlive]]
+- [[plugins/htmltidy]] depends on [[!debpkg tidy]]
+- [[plugins/table]] depends on [[!debpkg libtext-csv-perl]]
+- [[plugins/textile]] depends on [[!debpkg libtext-textile-perl]]
+- [[plugins/txt]] should probably just depend on [[!debpkg liburi-find-perl]]
+- [[plugins/sparkline]] depends on [[!debpkg libsparkline-php]], which pulls in the whole PHP stack.
+  - [[plugins/postsparkline]] depends on the sparkline plugin, so it should probably go in the same package.
+- [[plugins/search]] depends on [[!debpkg xapian-omega]] and [[!debpkg libsearch-xapian-perl]]
+- [[plugins/po]] depends on [[!debpkg po4a]] (and possibly [[!debpkg gettext]] and [[!debpkg liblocale-gettext-perl]], or does something else use those?)
+- [[plugins/amazon_s3]] depends on [[!debpkg libnet-amazon-s3-perl]] and [[!debpkg libfile-mimeinfo-perl]]
+- [[plugins/highlight]] depends on [[!debpkg libhighlight-perl]]
+- [[plugins/htmlbalance]] depends on [[!debpkg libhtml-tree-perl]]
+- [[plugins/typography]] depends on [[!debpkg libtext-typography-perl]]
+- [[plugins/creole]] depends on [[!debpkg libtext-wikicreole-perl]]
+- [[plugins/wikitext]] depends on [[!debpkg libtext-wikiformat-perl]]
+- [[plugins/rst]] depends on [[!debpkg librpc-xml-perl]] and [[!debpkg python-docutils]], and pulls in Python
+- [[plugins/blogspam]] depends on [[!debpkg librpc-xml-perl]]
+- [[plugins/prettydate]] depends on [[!debpkg libtimedate-perl]]
+- [[plugins/hnb]] depends on [[!debpkg hnb]]
+- [[plugins/fortune]] depends on [[!debpkg fortune]]
+- [[plugins/filecheck]] depends on [[!debpkg libfile-mimeinfo-perl]] and file
+- [[plugins/ddate]] depends on [[!debpkg libdatetime-calendar-discordian-perl]] and [[!debpkg libdatetime-perl]]
+- [[plugins/otl]] depends on [[!debpkg vim-vimoutliner]]
+- [[plugins/haiku]] depends on [[!debpkg libcoy-perl]]
+- [[plugins/sortnaturally]] depends on [[!debpkg libsort-naturally-perl]]
+- [[plugins/pinger]] depends on [[!debpkg liblwpx-paranoidagent-perl]] (it works with plain LWP, but less securely) and should probably just depend on [[!debpkg libcrypt-ssleay-perl]]
+- [[plugins/openid]] depends on [[!debpkg libnet-openid-consumer-perl]], and should either recommend or just depend on [[!debpkg liblwpx-paranoidagent-perl]] and [[!debpkg libcrypt-ssleay-perl]]
+- Support for tla depends on [[!debpkg libmailtools-perl]] (could make this a package depending on [[!debpkg tla]] and [[!debpkg libmailtools-perl]])
+
+Also, ikiwiki should probably just depend on [[!debpkg libauthen-passphrase-perl]] and refuse to store insecure passwords.
+
+[[!tag wishlist]]
diff --git a/doc/todo/Support_MultiMarkdown_3.X.mdwn b/doc/todo/Support_MultiMarkdown_3.X.mdwn
index f7f0ec8e5..ad724442b 100644
--- a/doc/todo/Support_MultiMarkdown_3.X.mdwn
+++ b/doc/todo/Support_MultiMarkdown_3.X.mdwn
@@ -7,4 +7,4 @@ but I'd rather not change the system file or uninstall the perl modules.
 Perhaps a custom Plugin/mdwn.pm or a clever way to set $markdown_sub would suffice,
 but I don't know perl.  If I wanted to replace Plugin/mdwn.pm with something simple
 that didn't bother to check for Text::*Markdown, calling /home/me/bin/mymdwn instead,
-what would that look like?
+what would that look like? -- [[tjgolubi]]
diff --git a/doc/todo/Wikilink_to_a_symbolic_link.mdwn b/doc/todo/Wikilink_to_a_symbolic_link.mdwn
new file mode 100644
index 000000000..1f9a12d9c
--- /dev/null
+++ b/doc/todo/Wikilink_to_a_symbolic_link.mdwn
@@ -0,0 +1,5 @@
+Some time ago I asked in the [[ikiwiki forum|http://ikiwiki.info/forum/Wikilink_to_a_symbolic_link/]] how to create wikilinks to symbolic links. The answer was that this is not possible because of security reasons.
+
+However I use ikiwiki only locally for my personal use. So it wouldn't be a security issue for me. The point is, that I want to link to pdf-files that are somewhere on my harddrive because I want to have automatically the newest versions of the files linked to in my ikiwiki. So my idea would be to create a symbolic links to those files in my scrdir.
+
+Would be great if something like that would be possible soon.
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 38c30c23f..f548f1a5b 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -161,3 +161,9 @@ definitions essentially.
 >>>>>>> No pity required — but whoops, yes, that was a bit of a mistake
 >>>>>>> ☺ I guess I'll have to split the current `preprocess` in half.
 >>>>>>> — [[Jon]]
+
+>>>>>>>> I've been taking another look at this today, as I'm very keen to
+>>>>>>>> close various open loops of mine in IkiWiki to move on and do some
+>>>>>>>> other stuff.  However, I'm not actually *using* this at the moment,
+>>>>>>>> so whilst I think it's a good idea, I can't really motivate myself
+>>>>>>>> to fix it anymore. I guess for now, this should just rot. — [[Jon]]
diff --git a/doc/todo/comment_moderation_feed.mdwn b/doc/todo/comment_moderation_feed.mdwn
index 267706b1b..996de152d 100644
--- a/doc/todo/comment_moderation_feed.mdwn
+++ b/doc/todo/comment_moderation_feed.mdwn
@@ -7,3 +7,10 @@ the author. It would be especially handy if it was generated statically.
 One way would be to generate internal pages corresponding to each comment
 that needs moderation; then the feed could be constructed via a usual
 inline.
+
+----
+
+See [[tips/comments feed]] --liw
+
+> Indeed, and the demo blog comes with a comments page with such feeds
+> already set up. [[done]] --[[Joey]] 
diff --git a/doc/todo/configurable_tidy_command_for_htmltidy.mdwn b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn
index e317184b5..2a7ebce0a 100644
--- a/doc/todo/configurable_tidy_command_for_htmltidy.mdwn
+++ b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn
@@ -3,6 +3,6 @@
 I was trying to get htmltidy to [play nicely with MathML][play].  Unfortunately, I couldn't construct a command line that I was happy with, but along the way I altered htmltidy to allow a configurable command line.  This seemed like a generally useful thing, so I've published my [patch][] as a Git branch.
 
 [play]: http://lists.w3.org/Archives/Public/html-tidy/2006JanMar/0052.html
-[patch]: http://www.physics.drexel.edu/~wking/code/git/git.php?p=ikiwiki.git&a=commitdiff&h=408ee89fd7c1dc70510385a7cf263a05862dda97&hb=e65ce4f0937eaf622846c02a9d39fa7aebe4af12
+[patch]: http://git.tremily.us/?p=ikiwiki.git&a=commitdiff&h=408ee89fd7c1dc70510385a7cf263a05862dda97&hb=e65ce4f0937eaf622846c02a9d39fa7aebe4af12
 
 > Thanks, [[done]] --[[Joey]] 
diff --git a/doc/todo/hyphenation.mdwn b/doc/todo/hyphenation.mdwn
new file mode 100644
index 000000000..e7f6bc401
--- /dev/null
+++ b/doc/todo/hyphenation.mdwn
@@ -0,0 +1,32 @@
+[[!tag wishlist]]
+
+I recently found [Hyphenator](http://code.google.com/p/hyphenator/) which is quite cool ... but it should be possible to implement this functionality within ikiwiki and not rely on javascript and the client.
+
+A Perl implementation of the algorithm exists in [[!cpan TeX::Hyphen]].
+
+> I'd be inclined to say that Javascript run in the client is a better
+> place to do hyphenation: this is the sort of non-essential,
+> progressive-enhancement thing that JS is perfect for. If you did it
+> at the server side, to cope with browser windows of different sizes
+> you'd have to serve HTML sprinkled with soft-hyphen entities at
+> every possible hyphenation point, like
+>
+>     pro&shy;gress&shy;ive en&shy;hance&shy;ment
+>
+> which is nearly twice the byte-count and might stop
+> search engines from indexing your site correctly.
+>
+> A browser that supports Javascript probably also supports
+> soft-hyphen marks, but I doubt all non-JS browsers support them
+> correctly.
+>
+> It might be good to have a plugin to insert a reference to the
+> hyphenation JS into the `<head>`, or a general way to enable
+> this sort of thing without writing a plugin or changing your
+> `page.tmpl`, though. Perhaps we should have a `local.js`
+> alongside `local.css`? :-)
+>
+> --[[smcv]]
+
+>> Thanks, I did not realize that the javascript does something else than add &amp;shy;s - took a closer look at it now.
+>> I doubt however that adding them will increase the byte count more than transmitting the javascript.
diff --git a/doc/todo/inline_raw_files.mdwn b/doc/todo/inline_raw_files.mdwn
index 8228186f9..52a4be726 100644
--- a/doc/todo/inline_raw_files.mdwn
+++ b/doc/todo/inline_raw_files.mdwn
@@ -9,7 +9,7 @@ Also raise an error in `IkiWiki::pagetype($file)` if `$file` is blank, which avo
 
 I'm using the new code in my [blog][].
 
-[blog]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/yacc2dot/
+[blog]: http://blog.tremily.us/posts/yacc2dot/
 
 usage
 =====
diff --git a/doc/todo/mdwn_itex.mdwn b/doc/todo/mdwn_itex.mdwn
index 3e304fa76..ae9a8f37a 100644
--- a/doc/todo/mdwn_itex.mdwn
+++ b/doc/todo/mdwn_itex.mdwn
@@ -19,4 +19,4 @@ MathML.
 
 [itex]: http://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html
 [itex2MML]: http://golem.ph.utexas.edu/~distler/blog/itex2MML.html
-[example]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/mdwn_itex/
+[example]: http://blog.tremily.us/posts/mdwn_itex/
diff --git a/doc/todo/mdwn_preview/discussion.mdwn b/doc/todo/mdwn_preview/discussion.mdwn
new file mode 100644
index 000000000..4fb30adf9
--- /dev/null
+++ b/doc/todo/mdwn_preview/discussion.mdwn
@@ -0,0 +1 @@
++1, not sure where this feature is going. I'm keen to seen this!
diff --git a/doc/todo/multi-thread_ikiwiki.mdwn b/doc/todo/multi-thread_ikiwiki.mdwn
index 1494fed7a..358185a22 100644
--- a/doc/todo/multi-thread_ikiwiki.mdwn
+++ b/doc/todo/multi-thread_ikiwiki.mdwn
@@ -6,3 +6,84 @@ Lots of \[[!img ]] (~2200), lots of \[[!teximg ]] (~2700). A complete rebuild ta
 We could use a big machine, with plenty of CPUs. Could some multi-threading support be added to ikiwiki, by forking out all the external heavy  plugins (imagemagick, tex, ...) and/or by processing pages in parallel?
 
 Disclaimer: I know nothing of the Perl approach to parallel processing.
+
+> I agree that it would be lovely to be able to use multiple processors to speed up rebuilds on big sites (I have a big site myself), but, taking a quick look at what Perl threads entails, and taking into acount what I've seen of the code of IkiWiki, it would take a massive rewrite to make IkiWiki thread-safe - the API would have to be completely rewritten - and then more work again to introduce threading itself.  So my unofficial humble opinion is that it's unlikely to be done.
+> Which is a pity, and I hope I'm mistaken about it.
+> --[[KathrynAndersen]]
+
+> > I have much less experience with the internals of Ikiwiki, much
+> > less Multi-threading perl, but I agree that to make Ikiwiki thread
+> > safe and to make the modifications to really take advantage of the
+> > threads is probably beyond the realm of reasonable
+> > expectations. Having said that, I wonder if there aren't ways to
+> > make Ikiwiki perform better for these big cases where the only
+> > option is to wait for it to grind through everything. Something
+> > along the lines of doing all of the aggregation and dependency
+> > heavy stuff early on, and then doing all of the page rendering
+> > stuff at the end quasi-asynchronously? Or am I way off in the deep
+> > end.
+> >
+> > From a practical perspective, it seems like these massive rebuild
+> > situations represent a really small subset of ikiwiki builds. Most
+> > sites are pretty small, and most sites need full rebuilds very
+> > very infrequently. In that scope, 10 minute rebuilds aren't that
+> > bad seeming. In terms of performance challenges, it's the one page
+> > with 3-5 dependency that takes 10 seconds (say) to rebuild that's
+> > a larger challenge for Ikiwiki as a whole. At the same time, I'd
+> > be willing to bet that performance benefits for these really big
+> > repositories for using fast disks (i.e. SSDs) could probably just
+> > about meet the benefit of most of the threading/async work.
+> >
+> > --[[tychoish]]
+
+>>> It's at this point that doing profiling for a particular site would come
+>>> in, because it would depend on the site content and how exactly IkiWiki is
+>>> being used as to what the performance bottlenecks would be.  For the
+>>> original poster, it would be image processing.  For me, it tends to be
+>>> PageSpecs, because I have a lot of maps and reports.
+
+>>> But I sincerely don't think that Disk I/O is the main bottleneck, not when
+>>> the original poster mentions CPU usage, and also in my experience, I see
+>>> IkiWiki chewing up 100% CPU usage one CPU, while the others remain idle.  I
+>>> haven't noticed slowdowns due to waiting for disk I/O, whether that be a
+>>> system with HD or SSD storage.
+
+>>> I agree that large sites are probably not the most common use-case, but it
+>>> can be a chicken-and-egg situation with large sites and complete rebuilds,
+>>> since it can often be the case with a large site that rebuilding based on
+>>> dependencies takes *longer* than rebuilding the site from scratch, simply
+>>> because there are so many pages that are interdependent.  It's not always
+>>> the number of pages itself, but how the site is being used.  If IkiWiki is
+>>> used with the absolute minimum number of page-dependencies - that is, no
+>>> maps, no sitemaps, no trails, no tags, no backlinks, no albums - then one
+>>> can have a very large number of pages without having performance problems.
+>>> But when you have a change in PageA affecting PageB which affects PageC,
+>>> PageD, PageE and PageF, then performance can drop off horribly.  And it's a
+>>> trade-off, because having features that interlink pages automatically is
+>>> really nifty ad useful - but they have a price.
+
+>>> I'm not really sure what the best solution is.  Me, I profile my IkiWiki builds and try to tweak performance for them... but there's only so much I can do.
+>>> --[[KathrynAndersen]]
+
+>>>> IMHO, the best way to get a multithreaded ikiwiki is to rewrite it
+>>>> in haskell, using as much pure code as possible. Many avenues
+>>>> then would open up to taking advantage of haskell's ability to
+>>>> parallize pure code.
+>>>>
+>>>> With that said, we already have some nice invariants that could be
+>>>> used to parallelize page builds. In particular, we know that
+>>>> page A never needs state built up while building page B, for any
+>>>> pages A and B that don't have a dependency relationship -- and ikiwiki
+>>>> tracks such dependency relationships, although not currently in a form
+>>>> that makes it very easy (or fast..) to pick out such groups of
+>>>> unrelated pages.
+>>>> 
+>>>> OTOH, there are problems.. building page A can result in changes to
+>>>> ikiwiki's state; building page B can result in other changes. All
+>>>> such changes would have to be made thread-safely. And would the
+>>>> resulting lock contention result in a program that ran any faster
+>>>> once parallelized?
+>>>> 
+>>>> Which is why [[rewrite_ikiwiki_in_haskell]], while pretty insane, is
+>>>> something I keep thinking about. If only I had a spare year..
+>>>> --[[Joey]]
diff --git a/doc/todo/natural_sorting.mdwn b/doc/todo/natural_sorting.mdwn
index 5df17e95b..3c42a4f94 100644
--- a/doc/todo/natural_sorting.mdwn
+++ b/doc/todo/natural_sorting.mdwn
@@ -7,7 +7,7 @@ page titles if they have numeric components. the
 provides an algorithm for that.
 
 there is a
-[patch](http://git.ikiwiki.info/?p=ikiwiki;a=commit;h=55b83cb7bd1cd7c60bb45dc22c3745dd80a63fed)
+patch 55b83cb7bd1cd7c60bb45dc22c3745dd80a63fed
 attached that makes the [[plugins/inline]] plugin use Sort::Naturally if sort
 is set to "title_natural".
 
diff --git a/doc/todo/org_mode.mdwn b/doc/todo/org_mode.mdwn
index 3e9d95376..ef7f4dbaf 100644
--- a/doc/todo/org_mode.mdwn
+++ b/doc/todo/org_mode.mdwn
@@ -18,7 +18,18 @@ but Ikiwiki currently (as far as I know) lacks a method to escape
 inserted HTML depending on which plugins will be used during the
 [[htmlize phase|plugins/write#index11h3]].
 
+new plugin
+==========
+
+A complete rewrite of the plugin can be found
+[here][chrismgray-rewrite].  It is an [[external|plugins/write/external]] plugin using a
+dedicated emacs instance to parse the org-mode files.  Thus, it should
+be a bit faster than the older plugin, as well as properly handling
+[[wikilinks|ikiwiki/wikilink]] and images, two features not present in the older
+plugin.
+
 [org-mode]: http://orgmode.org/
 [MS]: http://www.golden-gryphon.com/blog/manoj/blog/2008/06/08/Using_org-mode_with_Ikiwiki/
-[example]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/Git/notes/
+[example]: http://blog.tremily.us/posts/Git/notes/
 [raw]: http://orgmode.org/manual/Quoting-HTML-tags.html
+[chrismgray-rewrite]: https://github.com/chrismgray/ikiwiki-org-plugin
diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn
index 209ec5435..748444a2f 100644
--- a/doc/todo/pagespec_aliases.mdwn
+++ b/doc/todo/pagespec_aliases.mdwn
@@ -100,6 +100,10 @@ however, to add ' or internal()' to `boring`, for some reason.
 >>>> for this patch. I personally like special pages like Kathryn is doing
 >>>> more than complex setup files. --[[Joey]]
 
+>>>>> I've ran out of time to keep working on this, so I'm just going to
+>>>>> submit it as a 'contrib' plugin and leave things at that for now.
+>>>>> — [[Jon]]
+
 ---------------------------
 
 Based on the above, I have written an experimental plugin called "subset".
@@ -162,3 +166,4 @@ Unfortunately I haven't figured out how to do the dependencies - I'd really appr
 >>>>> I'm a bit confused by your statement "having the aliases/subsets/"things" work in any pagespec (inside map, or inline) is a deal-breaker for me".
 >>>>> Do you mean that you want them to work in any pagespec, or that you *don't* want them to work in any pagespec? -- [[KathrynAndersen]]
 
+>>>>>> I mean I would want them to work in any pagespec. — [[Jon]]
diff --git a/doc/todo/pdf_output.mdwn b/doc/todo/pdf_output.mdwn
index 1a1411093..29c89e4eb 100644
--- a/doc/todo/pdf_output.mdwn
+++ b/doc/todo/pdf_output.mdwn
@@ -4,3 +4,17 @@ Note that for example dokuwiki has a [[nice plugin|http://danjer.doudouke.org/te
 
 > I've actually written one, it's just not publicly released.  You can check it out from the "experimental" branch of my <a href="https://github.com/rubykat/ikiplugins">ikiplugins githup repo</a>.  It's called "html2pdf" and it depends on the static version of <a href="http://code.google.com/p/wkhtmltopdf/">wkhtmltopdf</a> rather than requiring a whole LaTeX setup. It's only been used on Ubuntu, so I can't say what problems there might be on other setups, but it works for me.  It's not properly documented; I'd appreciate some help with that.
 > -- [[KathrynAndersen]]
+
+>> Thanks, I downloaded the git-repro and did `sudo cp html2pdf.pm /usr/share/perl5/IkiWiki/Plugin/` then I added html2pdf to the addplugins line in my setup-file (`mywiki.setup`) as well a new line `html2pdf_pages=>"/*",`. Then I did `sudo ikiwiki --setup mywiki.setup`. However there is no button or something like that which let's me create the pdf's
+>> -- [[micheal]]
+
+>>> That is because they are created automatically as part of the page-build process.  That's what the "html2pdf_pages" option is for: it defines which pages have PDFs generated from them.  If a PDF is generated for page "foo", then the PDF itself will be in "foo/foo.pdf".
+
+>>> I also notice you didn't mention installing wkhtmltopdf - it won't create PDFs without that!
+>>> -- [[KathrynAndersen]]
+
+>>>> Yes, wkhtmltopdf is installed and works, however there are no pdf-files in my /var/www/myiki directory or in scrdir. 
+
+>>>>> Have you tried running it with "verbose" turned on, and noting the output?  That could give some clues.
+>>>>> And no, the PDFs are not placed in the source dir, only in the destination dir.
+>>>>> -- [[KathrynAndersen]]
diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
index 48ed744b1..e48765b0e 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
@@ -62,8 +62,4 @@ Some other things to be scared about:
   a bunch of haskell libraries. OTOH, it might be possible to build a
   static binary at home and upload it, thus avoiding a messy installation
   procedure entirely.
-* I can barely code in haskell yet. I'm probably about 100x faster at
-  programming in perl. I need to get some more practical experience before
-  I´m fast and seasoned enough in haskell to attempt such a project.
-  (And so far, progress at learning has been slow and I have not managed
-  to write anything serious in haskell.) --[[Joey]] 
+  --[[Joey]] 
diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
index 1edebe4e8..b6495194a 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -12,3 +12,46 @@ Congratulations for demonstrating that April fools jokes can still be subtle
 >>> It doesn't really. I recently (re-)read about couchdb and thought that
 >>> what it was trying to do had some comparisons with the thinking going on
 >>> in [[todo/structured_page_data]]. -- [[Jon]]
+
+-----
+
+I'm torn about this idea, if it's actually serious.  I'm very comfortable
+programming in Perl, and have written quite a few modules for IkiWiki, and
+it would be a huge pain to have to start from scratch all over again. On
+the other hand, this could be a motivation for me to learn Haskell.  My
+only encounter with Haskell has been a brief time when I was using the
+Xmonad window manager, but it looks like an interesting language.
+Functional programming is cool.
+
+There are a lot of interesting plusses for Haskell you note (in the parent
+page), but it's true that the idea is horribly daunting (as [[Joey]] said
+"If only I had a spare year").  Is there any way that you could "start
+small"?  Because nothing will ever happen if the task is too daunting to
+even start.
+
+> This seems destined to remain a thought experiment unless something like
+> that can be done, or I get a serious case of second system disease.
+> 
+> I've considered doing things like using the external plugin interface
+> to run a separate haskell program, which would allow implementing
+> arbitrary plugins in haskell (starting with a pandoc plugin..),
+> and could perhaps grow to subsume the perl code. However, this would
+> stick us with the perl data structures, which are not a very good fit
+> for haskell. --[[Joey]]
+
+On further thought... perhaps it would be easier to fork or contribute to
+an existing Haskell-based wiki, such as <a
+href="http://jaspervdj.be/hakyll">Hakyll</a>?
+
+--[[KathrynAndersen]]
+
+> As far as I know there are no other wikis (haskell or otherwise)
+> that are wiki compilers. Since we know from experience that dealing
+> with static compilation turns out to be one of the trickiest parts of
+> ikiwiki, I'm doubtful about trying to bolt that into one. --[[Joey]] 
+
+>> Haykll isn't a wiki but it does do static compilation. The missing
+>> parts are: the web interface, the wiki link processing, and page
+>> dependency stuff. -- [[tychoish]]
+
+>>> (nods) Which is why I suggested it.  I'm not sure whether it would be easier to "bolt on" those things than static compilation, but it could be worth looking at, at least. -- [[KathrynAndersen]]
diff --git a/doc/todo/sortbylastcomment_plugin.mdwn b/doc/todo/sortbylastcomment_plugin.mdwn
index 71dfb67c8..84cf86e21 100644
--- a/doc/todo/sortbylastcomment_plugin.mdwn
+++ b/doc/todo/sortbylastcomment_plugin.mdwn
@@ -9,3 +9,5 @@ You'll find it in this repository, in the 'sortbylastcomment' branch:
 [[!tag wishlist patch]]
 
 > Reviewed, tested: looks good to me. We need it for the [Tails forum](https://tails.boum.org/forum/). --[[intrigeri]]
+
+>> Hi, is there a chance of seeing this plugin getting included in a release at any point soon? --sajolida
diff --git a/doc/todo/sorting_by_path.mdwn b/doc/todo/sorting_by_path.mdwn
new file mode 100644
index 000000000..a483c331a
--- /dev/null
+++ b/doc/todo/sorting_by_path.mdwn
@@ -0,0 +1,18 @@
+[[!tag patch]]
+[[!template id=gitbranch branch=smcv/trail3 author="[[smcv]]"]]
+
+My branch for [[plugins/contrib/trail]] also includes `path`
+and `path_natural` sort orders, which sort the entire page name,
+e.g. "a a/z ab ab/c b", much like [[ikiwiki/directive/map]].
+I used `path` as the default order for the
+[[plugins/contrib/ikiwiki/directive/trailitems]] directive,
+since it seemed the most sensible.
+([[plugins/contrib/ikiwiki/directive/trailinline]] uses
+`age` as its default, to be consistent with `inline`.)
+
+It's one commit (including a regression test) which can be
+cherry-picked if you don't want the rest of `trail`.
+
+--[[smcv]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/submodule_support.mdwn b/doc/todo/submodule_support.mdwn
new file mode 100644
index 000000000..d6a7edb03
--- /dev/null
+++ b/doc/todo/submodule_support.mdwn
@@ -0,0 +1,15 @@
+I would love to be able to publish my theme in my personnal wiki. The theme is in a separate git repository, and i feel it would be pretty awesome if it was rendered within my main ikiwiki site. I have tried the following:
+
+    git submodule add /usr/share/ikiwiki/themes/night_city/
+    git commit -m"add the theme to my site" ; git push
+
+But this made really weird things on the other side. The files from the theme end up flat in the parent directory. Now I have reverted the above change and ikiwiki *still* generates those files. Not sure what is going on. 
+
+To be really clear here: this is an arbitrary source code repository that I want to include, I do not mean to enable the theme with this, this could very well be presentation material, C source code or whatever else... In fact, I think this would be a powerful way to do syntax highlightning for source code published on your website...
+
+Other people had experience with this? Or other suggestions on how to publish repositories within my site? -- [[anarcat]]
+
+> Ikiwiki does not support git submodules. 
+> 
+> You can use the [[plugins/underlay]] plugin to merge the
+> contents of other directories into your wiki's source. --[[Joey]] 
diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn
index aae0b3008..420ae4a7e 100644
--- a/doc/todo/supporting_comments_via_disussion_pages.mdwn
+++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn
@@ -218,3 +218,5 @@ I've updated smcvpostcomment and publicised it as [[plugins/contrib/comments]].
 
 > While there is still room for improvement and entirely other approaches,
 > I am calling this done since smcv's comments plugin is ready. --[[Joey]] 
+
+[[done]]
diff --git a/doc/todo/test_coverage.mdwn b/doc/todo/test_coverage.mdwn
new file mode 100644
index 000000000..56e11e01a
--- /dev/null
+++ b/doc/todo/test_coverage.mdwn
@@ -0,0 +1,24 @@
+[[!tag patch]]
+[[!template id=gitbranch branch=smcv/coverage author="[[smcv]]"]]
+
+It would be nice for `make coverage` (or something) to produce a HTML
+test-coverage report. I found this very useful for test-driven development of
+[[plugins/contrib/trail]].
+
+Limitations of the current branch, which uses [[!cpan Devel::Cover]]:
+
+* Some tests use `./blib` and some use `.` so coverage gets split between
+  the two copies of each module; not a problem for [[plugins/contrib/trail]]
+  which only has one test.
+
+> How annoying. I think in at least some cases there is reason to use
+> `./blib` -- perhaps everything that users `.` should be changed to use
+> it. --[[Joey]]
+
+* The [[plugins/git]] and [[plugins/mercurial]] plugins want to `chdir`,
+  and so does [[!cpan Devel::Cover]], so they fight. For now, those tests
+  are disabled under `make coverage`.
+
+--[[smcv]]
+
+> [[merged|done]] --[[Joey]]
diff --git a/doc/todo/themes_should_ship_with_templates.mdwn b/doc/todo/themes_should_ship_with_templates.mdwn
new file mode 100644
index 000000000..875e5ce89
--- /dev/null
+++ b/doc/todo/themes_should_ship_with_templates.mdwn
@@ -0,0 +1,19 @@
+if i understand [[todo/multiple_template_directories]] correctly, i read it as templates directories being separate from themes. shouldn't a themer be able to ship more than just a CSS and instead override the (say) page.tmpl page? -- [[anarcat]]
+
+> A theme can ship any files it wants to, including templates (in the
+> templates/ directory).
+> 
+> So far none of them do; I'd much rather have one version of page.tmpl to
+> maintain than one per theme.. --[[Joey]]
+
+> > that, dear author, is amazingly simple, intuitive and useful. why didn't i try this before! :) thank you very much!
+> > 
+> > i do agree that having a completely different template file is tricky, but I think it's important for themes to be able to modify those files, otherwise making themes is *really* hard. besides the burden of maintenance falls on the theme maintainer, and as long as it's not in ikiwiki core, you have nothing to worry about... right? ;)
+> > 
+> > i have just ported the [night_city theme](http://www.openwebdesign.org/viewdesign.phtml?id=3318) to ikiwiki, and it was a nightmare when i wasn't modifying the page.tmpl... but now it's done! i'll try to publish my changes somewhere when i finish figuring out how to share small things like that easily. ;) ([[suggestions|submodule_support]]?)
+> > 
+> > i guess the only thing to be done here is to update the documentation so that this is clearer - where do you suggest I do that? --[[anarcat]]
+> > 
+> > > i have updated the [[plugins/theme]] documentation, hopefully that was the right place. so i think this is [[done]] --[[anarcat]]
+
+>>>> I would love it it you would share your theme!  Thanks, Adam. :-)
diff --git a/doc/todo/websetup_should_link_to_plugin_descriptions.mdwn b/doc/todo/websetup_should_link_to_plugin_descriptions.mdwn
new file mode 100644
index 000000000..8b15fb7d0
--- /dev/null
+++ b/doc/todo/websetup_should_link_to_plugin_descriptions.mdwn
@@ -0,0 +1,3 @@
+A [[wishlist]] item.
+
+It would be nice if the websetup plugin could link to plugin descriptions. When it refers to a plugin by name, the name could be a link to <http://ikiwiki.info/plugins/$NAME/> (or other suitable location). --liw
diff --git a/doc/todo/wikitrails.mdwn b/doc/todo/wikitrails.mdwn
index ca97c9404..f2f87ac82 100644
--- a/doc/todo/wikitrails.mdwn
+++ b/doc/todo/wikitrails.mdwn
@@ -1,17 +1,25 @@
 ## summary
 at times it is useful to have a guided tour or trail through a subset of the pages of a wiki; in pmwiki, this is implemented as [wikitrails](http://www.pmwiki.org/wiki/PmWiki/WikiTrails).
 
+### smcv's implementation
+
+... is the out-of-tree [[plugins/contrib/trail]] plugin, see there for details.
+
+> And will be the one landing in ikiwiki. So, I'm closing this bug report. [[done]] --[[Joey]]
+
+### chrysn's implementation
+
 i'm working on a python xmlrpc plugin for ikiwiki to support wikitrails, both as a navigation feature (have "forward" and "back" links based on a sequence) and a modified inline that includes all pages in the trail with appropriate modifications (suitable for printing if necessary).
 
 the current status is published on `git://github.com/github076986099/ikiwiki-plugins.git`; as of now, i don't have a public demo of it.
 
 feedback on both the concept and the code is very much appreciated by [[discussion]] or [email](mailto:chrysn@fsfe.org).
 
-## usage
+#### usage
 
 two preprocessor commands are provided:
 
-### \[[!trail index="my_indexpage"]]
+##### \[[!trail index="my_indexpage"]]
 
 embeds a navigation object with forward and back links as well as an indicator of the current position in the trail.
 
@@ -19,15 +27,15 @@ if index is not specified, a suitable page up the path is used.
 
 this works very well together with the [[sidebar|plugins/sidebar]] plugin if the pages in a directory are roughly the same as the pages in the trail and the `index` is directory index page; just put the \[[!trail]] in the sidebar.
 
-### \[[!trailinclude index="my_indexpage"]]
+##### \[[!trailinclude index="my_indexpage"]]
 
 all pages linked from the index page are included in the same way as \[[!inline]] does, but in the proper sequence, with headings according to the indent in the source page and adoptions for the headings inside the page (a level 2 heading in a page that is a sub-sub-chapter in the whole trail will become a level 5 heading when trailincluded).
 
-## the index page
+#### the index page
 
 the index page is parsed as markdown; numbered lists and "`*`" bulleted lists are discovered.
 
-## current issues
+#### current issues
 
  * rebuilding --- currently, there is no propper rebuilding of pages (will use `will_render` and `add_depends`). care has to be taken of how not yet created pages play into this.
  * inline recursion --- there is simply no guard yet
diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn
index 9dbbb6bc8..1ceb51f0d 100644
--- a/doc/todo/wikitrails/discussion.mdwn
+++ b/doc/todo/wikitrails/discussion.mdwn
@@ -1,3 +1,7 @@
+(This mainly discusses the original implementation (chrysn's). --[[smcv]])
+
+----
+
 This is a nice idea, I do have my gripes about the imeplementation.
 
 Assuming that the index's list is in mdwn format is not ideal. I guess the
diff --git a/doc/todo/wmd_editor_live_preview.mdwn b/doc/todo/wmd_editor_live_preview.mdwn
new file mode 100644
index 000000000..d76fb2ba4
--- /dev/null
+++ b/doc/todo/wmd_editor_live_preview.mdwn
@@ -0,0 +1,11 @@
+Some time ago there was [[a question|http://ikiwiki.info/forum/wmd_editor_double_preview/]] in the forum about wmd editor and preview. However there were no answers:
+
+I use the wmd editor in my ikiwiki. However live preview seems not to be a fully correct preview so nevertheless I have to hit the preview button to get a correct preview. However then I have two previews so that I have to scroll down to see the correct one.
+
+Is it possible to disable the live preview or to replace the live preview with the correct one after pressing the preview button?
+
+> There's another page already tracking this UI problem: [[mdwn_preview]]
+> There is a patch there, but AFAIK nobody has done any more work on
+> WMD integration with ikiwiki. --[[Joey]]
+
+>> I tried to apply the patch via git apply, however get an error: fatal: corrupt patch at line 63, any idea?