From: Joey Hess <joey@kitenet.net>
Date: Mon, 4 Mar 2013 17:19:31 +0000 (-0400)
Subject: Merge branch 'master' of ssh://git.ikiwiki.info
X-Git-Tag: 3.20130504~75
X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/d72e5fd58c121582b2a2a1feca39596c29a1feb0?hp=8c8aa3fe479ccbcc60d82b1efa38df2edf38fc15

Merge branch 'master' of ssh://git.ikiwiki.info
---

diff --git a/doc/bugs/map_generates_malformed_HTML.mdwn b/doc/bugs/map_generates_malformed_HTML.mdwn
new file mode 100644
index 000000000..e094264f4
--- /dev/null
+++ b/doc/bugs/map_generates_malformed_HTML.mdwn
@@ -0,0 +1,34 @@
+[[!template id=gitbranch branch=smcv/ready/map author="[[Simon McVittie|smcv]]"]]
+[[!tag patch]]
+
+`\[[!map]]` can generate bad HTML with unbalanced open/close tags
+(in XML terms: "not well-formed") in certain situations. This
+appears to be a regression caused by fixing
+[[maps with nested directories sometimes make ugly lists]], which
+suppressed some redundant `</ul><ul>` pairs, but appears not to
+have the ideal logic for this, leading to malformed HTML.
+
+In particular, on a site with these pages:
+
+* alpha
+    * 1
+        * i
+        * ii
+        * iii
+        * iv
+    * 2
+        * a
+        * b
+    * 3
+* beta
+
+the maps "`alpha/1 or beta`", "`alpha/1/i* or alpha/2/a or beta`" and
+"`alpha/1/i* or alpha/2/a`" have malformed HTML.
+
+My `ready/map` branch adds a regression test and makes it pass.
+
+The fix is not particularly elegant - it generates the previous
+HTML with redundant `</ul><ul>` pairs, marks the redundant
+pairs, and edits them out afterwards - but it works. If anyone can come
+up with a cleaner algorithm that avoids generating the redundant tags
+in the first place, that would be even better. --[[smcv]]
diff --git a/doc/bugs/removal_of_transient_pages.mdwn b/doc/bugs/removal_of_transient_pages.mdwn
index 4843b5900..6d0caf42e 100644
--- a/doc/bugs/removal_of_transient_pages.mdwn
+++ b/doc/bugs/removal_of_transient_pages.mdwn
@@ -65,7 +65,12 @@ inconsistent between the one-and two-argument forms. Thoughts?
 >> Try this, then? I had to make some changes to `attachment`
 >> to make the split versions available. I suggest reviewing
 >> patch-by-patch.
->>
+
+>>> Branch updated; I'd missed a use of prune in ikiwiki.in itself.
+>>> Unfortunately, this means it does still need to support the
+>>> "undefined top directory" case: there isn't an obvious top
+>>> directory for wrappers. --[[smcv]]
+
 >> I also tried to fix a related bug which I found while testing it:
 >> the special case for renaming held attachments didn't seem to work.
 >> (`smcv/wip/rename-held`.) Unfortunately, it seems that with that
diff --git a/doc/bugs/sidebar_not_updated_in_unedited_subpages.mdwn b/doc/bugs/sidebar_not_updated_in_unedited_subpages.mdwn
new file mode 100644
index 000000000..c3e0ee18c
--- /dev/null
+++ b/doc/bugs/sidebar_not_updated_in_unedited_subpages.mdwn
@@ -0,0 +1,9 @@
+I turned on the sidebar plugin, with global_sidebars on (in the web setup page), created a sidebar page in the root, and edited the sidebar a few times.
+
+I then noticed that all pages on the root had been updated with a sidebar, but no subpages (i.e. a/b). Only after editing a subpage did it get a sidebar. Editing sidebar itself only updated subpages with sidebars, the other subpages had not been refreshed (proven by their unchanged filesystem date)  
+
+After calling ikiwiki --setup on the command line all pages were updated. So this seems to be a difference between web-started --setup and command-line --setup. Or it just doesn't work the first time --setup is called after sidebars are enabled.
+
+
+
+
diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
new file mode 100644
index 000000000..79dccc136
--- /dev/null
+++ b/doc/bugs/template_creation_error.mdwn
@@ -0,0 +1,111 @@
+Hi,
+I am trying to build a template. The compilation of this template results in a weird exception. I have isolated the cause of the exception to the following point:
+
+If i have this in the template code:
+
+\[[!inline<br/>
+pages="\<TMPL_VAR SEL_PAGES\>"<br/>
+template=extract-entry<br/>
+\]]<br/>
+
+There is no problem at all. I can use the template with the desired result. But if I try to use this (just adding the "show" parameter):
+
+\[[!inline <br/>
+pages="\<TMPL_VAR SEL_PAGES>"<br/>
+template=extract-entry<br/>
+show=\<TMPL_VAR CNTPG><br/>
+\]]<br/>
+
+I get this exception on the Git bash console:
+
+<pre>
+$ git push
+Counting objects: 7, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (4/4), 410 bytes, done.
+Total 4 (delta 3), reused 0 (delta 0)
+remote: From /home/b-odelama-com/source
+remote:    eb1421e..5e1bac5  master     -> origin/master
+remote: Argument "\x{3c}\x{54}..." isn't numeric in numeric lt (<) at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 231.
+remote: Argument "\x{3c}\x{54}..." isn't numeric in numeric lt (<) at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 231.
+To ssh://b-odelama-com@odelama-com.branchable.com/
+   eb1421e..5e1bac5  master -> master
+</pre>
+
+Please, let me know what to do to avoid this kind of error.
+
+> When you add a template page `templates/foo.mdwn` for use
+> the [[ikiwiki/directive/template]] directive, two things happen:
+>
+> 1. `\[[!template id=foo ...]]` becomes available;
+> 2. a wiki page `templates/foo` is built, resulting in a HTML file,
+>    typically `templates/foo/index.html`
+>
+> The warnings you're seeing are the second of these: when ikiwiki
+> tries to process `templates/foo.mdwn` as an ordinary page, without
+> interpreting the `<TMPL_VAR>` directives, `inline` receives invalid
+> input.
+>
+> This is a bit of a design flaw in [[plugins/template]] and
+> [[plugins/edittemplate]], I think - ideally it would be possible to
+> avoid parts of the page being interpreted when the page is being
+> rendered normally rather than being used as a template.
+>
+> There *is* a trick to avoid parts of the page being interpreted when
+> the page is being used as a template, while having them appear
+> when it's rendered as a page:
+>
+>     <TMPL_IF FALSE>
+>     <!-- This part only appears when being used as a page.
+>          It assumes that you never set FALSE to a true value :-) -->
+>     \[[!meta robots="noindex,nofollow"]]
+>     This template is used to describe a thing. Parameters:
+>     * name: the name of the thing
+>     * size: the size of the thing
+>     </TMPL_IF>
+>
+>     The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
+>
+> I suppose you could maybe extend that to something like this:
+>
+>     <TMPL_IF FALSE>
+>     <!-- This part only appears when being used as a page.
+>          It assumes that you never set FALSE to a true value :-) -->
+>     \[[!meta robots="noindex,nofollow"]]
+>     This template is used to describe a thing. Parameters:
+>     * name: the name of the thing
+>     * size: the size of the thing
+>     </TMPL_IF>
+>
+>     <TMPL_IF FALSE>
+>     \[[!if test="included() and !included()" then="""
+>     </TMPL_IF>
+>     <!-- This part only appears when being used as a template. It also
+>          assumes that you never set FALSE to a true value, and it
+>          relies on the [[ikiwiki/pagespec]] "included() and !included()"
+>          never being true. -->
+>     The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
+>     <TMPL_IF FALSE>
+>     """]]
+>     </TMPL_IF>
+>
+> but that's far harder than it ought to be!
+>
+> Perhaps the right solution would be to change how the template plugin
+> works, so that templates are expected to contain a new `definetemplate`
+> directive:
+>
+>     This template is used to describe a thing. Parameters:
+>     * name: the name of the thing
+>     * size: the size of the thing
+>     
+>     \[[!definetemplate """
+>     The thing is called <TMPL_VAR name> and its size is <TMPL_VAR size>
+>     """]]
+>
+> with templates not containing a `\[[!definetemplate]]` being treated
+> as if the whole text of the page was copied into a `\[[!definetemplate]]`,
+> for backwards compatibility?
+>
+> --[[smcv]]
diff --git a/doc/bugs/undefined_value_as_a_HASH_reference.mdwn b/doc/bugs/undefined_value_as_a_HASH_reference.mdwn
new file mode 100644
index 000000000..384e09336
--- /dev/null
+++ b/doc/bugs/undefined_value_as_a_HASH_reference.mdwn
@@ -0,0 +1,51 @@
+Hello,
+
+does anyone have an idea why I see the following error when I run websetup (Setup button in Preferences)?
+
+    Error: Can't use an undefined value as a HASH reference at /usr/share/perl5/IkiWiki/Plugin/websetup.pm line 82, line 97.
+
+Maybe, related to this is also
+
+    $ ikiwiki --setup /etc/ikiwiki/auto-blog.setup
+    What will the blog be named? tmpblog
+    What revision control system to use? git
+    What wiki user (or openid) will be admin? wsh
+
+
+    Setting up tmpblog ...
+    Importing /home/wsh/tmpblog into git
+    Initialized empty shared Git repository in /home/wsh/tmpblog.git/
+    Initialized empty Git repository in /home/wsh/tmpblog/.git/
+    [master (root-commit) d6847e1] initial commit
+     8 files changed, 48 insertions(+)
+     create mode 100644 .gitignore
+     create mode 100644 archives.mdwn
+     create mode 100644 comments.mdwn
+     create mode 100644 index.mdwn
+     create mode 100644 posts.mdwn
+     create mode 100644 posts/first_post.mdwn
+     create mode 100644 sidebar.mdwn
+     create mode 100644 tags.mdwn
+    Counting objects: 11, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (9/9), done.
+    Writing objects: 100% (11/11), 1.53 KiB, done.
+    Total 11 (delta 0), reused 0 (delta 0)
+    Unpacking objects: 100% (11/11), done.
+    To /home/wsh/tmpblog.git
+     * [new branch]      master -> master
+    Directory /home/wsh/tmpblog is now a clone of git repository /home/wsh/tmpblog.git
+    Reference found where even-sized list expected at /usr/share/perl5/IkiWiki/Setup.pm line 177, <GEN4> line 97.
+    Reference found where even-sized list expected at /usr/share/perl5/IkiWiki/Setup.pm line 224, <GEN4> line 97.
+    Use of uninitialized value $section in hash element at /usr/share/perl5/IkiWiki/Setup.pm line 226, <GEN4> line 97.
+    Use of uninitialized value $section in hash element at /usr/share/perl5/IkiWiki/Setup.pm line 227, <GEN4> line 97.
+    Use of uninitialized value $section in concatenation (.) or string at /usr/share/perl5/IkiWiki/Setup.pm line 233, <GEN4> line 97.
+    /etc/ikiwiki/auto-blog.setup: Can't use an undefined value as a HASH reference at /usr/share/perl5/IkiWiki/Setup.pm line 252, <GEN4> line 97.
+
+    usage: ikiwiki [options] source dest
+           ikiwiki --setup configfile
+
+I'm on Debian unstable.
+
+Thanks,
+-Michal
diff --git a/doc/forum/Email_notifications_for_comment_moderation.mdwn b/doc/forum/Email_notifications_for_comment_moderation.mdwn
new file mode 100644
index 000000000..6a840ce53
--- /dev/null
+++ b/doc/forum/Email_notifications_for_comment_moderation.mdwn
@@ -0,0 +1,3 @@
+I use both [[plugins/moderatedcomments/]] and [[plugins/anonok]] on my [blog](http://feeding.cloud.geek.nz) but having to remember to visit the comment moderation page manually is not ideal.
+
+Is there a way to get an email notification (or maybe even just an RSS feed) whenever a new comment enters the moderation queue?
diff --git a/doc/forum/Email_notifications_for_comment_moderation/comment_1_668bf6a21310dcc8b882bc60a130ba06._comment b/doc/forum/Email_notifications_for_comment_moderation/comment_1_668bf6a21310dcc8b882bc60a130ba06._comment
new file mode 100644
index 000000000..06140728e
--- /dev/null
+++ b/doc/forum/Email_notifications_for_comment_moderation/comment_1_668bf6a21310dcc8b882bc60a130ba06._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm6VdLM7IKcNgkDiJ2YKHpcWli9bRLsZDk"
+ nickname="Oscar"
+ subject="How to get a comment moderation feed"
+ date="2013-02-25T18:04:21Z"
+ content="""
+I was looking for the same subject and I have found the following:
+
+http://ikiwiki.info/tips/comments_feed/
+
+
+"""]]
diff --git a/doc/forum/How_to_set_up_a_page_as_internal__63__.mdwn b/doc/forum/How_to_set_up_a_page_as_internal__63__.mdwn
new file mode 100644
index 000000000..ed771292d
--- /dev/null
+++ b/doc/forum/How_to_set_up_a_page_as_internal__63__.mdwn
@@ -0,0 +1,5 @@
+I have a folder with few administrative tasks, like a page showing the comments waiting for moderation.
+
+There is no link from "normal/public" pages in my site to this administrative pages, but it doesn't prevent the possibility of any person writing down that address in the browser address-bar or finding that address in the browser navigation history.
+
+Please, is there any way or best-practice restricting the access to this kind of pages? I know that these pages will eventually ask the user to log-in as admin, but I don't want them to see this stuff.
diff --git a/doc/plugins/contrib/dynamiccookies.mdwn b/doc/plugins/contrib/dynamiccookies.mdwn
new file mode 100644
index 000000000..c43b18f6b
--- /dev/null
+++ b/doc/plugins/contrib/dynamiccookies.mdwn
@@ -0,0 +1,12 @@
+[[!template id=plugin name=dynamiccookies author="[[schmonz]]"]]
+[[!template id=gitbranch branch=schmonz/dynamiccookies author="[[schmonz]]"]]
+[[!tag type/web]]
+
+This plugin populates ikiwiki's cookiejar by calling an external
+program. The program is expected to print the serialized cookies
+on `stdout` in a form which can be `eval`'d (e.g., `Data::Dumper`).
+
+The plugin author's use case for this seemingly hacky interface:
+aggregating authenticated feeds at work, where for various reasons
+the needed cookies must be acquired using a separate `perl` from
+the one used by ikiwiki.
diff --git a/doc/plugins/contrib/proxies.mdwn b/doc/plugins/contrib/proxies.mdwn
new file mode 100644
index 000000000..dc53adf29
--- /dev/null
+++ b/doc/plugins/contrib/proxies.mdwn
@@ -0,0 +1,13 @@
+[[!template id=plugin name=proxies author="[[schmonz]]"]]
+[[!template id=gitbranch branch=schmonz/proxies author="[[schmonz]]"]]
+[[!tag type/format]]
+
+This plugin enables ikiwiki to open outbound connections (such as
+found in [[plugins/aggregate]], [[plugins/openid]], and [[plugins/pinger]])
+via a proxy. The proxy can be configurably avoided for connections
+to certain domains.
+
+### To do
+
+* Move duplicated user-agent setup out of other plugins into this one.
+* While I'm at it, fix [[bugs/http_proxy_for_openid]].
diff --git a/doc/plugins/contrib/wc.mdwn b/doc/plugins/contrib/wc.mdwn
new file mode 100644
index 000000000..fb5a7320e
--- /dev/null
+++ b/doc/plugins/contrib/wc.mdwn
@@ -0,0 +1,22 @@
+[[!template id=plugin name=wc author="[[schmonz]]"]]
+[[!template id=gitbranch branch=schmonz/wc author="[[schmonz]]"]]
+[[!tag type/meta]]
+[[!tag patch]]
+
+This plugin counts words in a page. For a single page, write a
+`\[[!wc]]` directive and the word count will be interpolated there.
+For a site, add `<TMPL_VAR WORDCOUNT>` to your [[templates]].
+
+If [[!cpan HTML::Strip]] is installed, the wordcount will be slightly
+more accurate.
+
+Possible enhancements:
+
+* Optimize: count words iff the result will be displayed. `sanitize()`
+  seems like the right place to count. Since it's called well after
+  `preprocess()`, I can tell whether a directive needs the result,
+  but since it appears to be called before `pagetemplate()`, I can't
+  tell whether a template wants to know and possibly skip the
+  computation. (In other words, if I add `$needed_for_template`
+  like `$needed_for_directive`, it gets set too late for `sanitize()`
+  to see.)
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 2b8202655..d6e6d8d1e 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -633,7 +633,7 @@ describes the plugin as a whole. For example:
   strictly required.
 * `section` can optionally specify which section in the config file
   the plugin fits in. The convention is to name the sections the
-  same as the tags used for [[plugins|plugin]] on this wiki.
+  same as the tags used for [[plugins]] on this wiki.
 
 ### genwrapper
 
@@ -684,7 +684,7 @@ wiki updates.
 
 The `%wikistate` hash can be used by a plugin to store persistant state
 that is not bound to any one page. To set a value, use
-`$wikistate{$id}{$key}=$value, where `$value` is anything Storable can
+`$wikistate{$id}{$key}=$value`, where `$value` is anything Storable can
 serialize, `$key` is any string you like, and `$id` must be the same as the
 "id" parameter passed to `hook()` when registering the plugin, so that the
 state can be dropped if the plugin is no longer used.
diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn
index 757190fb0..c7c91e4fb 100644
--- a/doc/sandbox.mdwn
+++ b/doc/sandbox.mdwn
@@ -1,6 +1,8 @@
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 
+hello world
+
 > This is a blockquote.
 >
 > This is the first level of quoting.
diff --git a/doc/todo/fancypodcast.mdwn b/doc/todo/fancypodcast.mdwn
new file mode 100644
index 000000000..8ce3dd3e7
--- /dev/null
+++ b/doc/todo/fancypodcast.mdwn
@@ -0,0 +1,117 @@
+ikiwiki's simple podcasting, while elegant and minimal, doesn't (as
+mentioned in [[todo/blogging]]) produce full-featured feeds. In
+fancy podcasts, episodes are accompanied by text content. The feeds
+also have lots more metadata.
+
+[[!toc]]
+
+## Design
+
+7. For each fancy podcast episode, write a blog post containing
+   `\[[!meta enclosure="WikiLink/to/media.mp3"]]`. (Don't specify
+   more than one enclosure -- but if you do, last one wins.)
+7. When rendering to HTML (single-page or inlined), append a link
+   to the media file.
+7. When rendering to RSS/Atom, the text is the entry's content and
+   the media file is its enclosure.
+7. Don't break simple podcasts in pursuit of fancy podcasts.
+
+## Implementation
+
+[[!template id=gitbranch branch=schmonz/fancypodcast author="[[schmonz]]"]]
+[[!tag patch]]
+
+### Completed
+
+* Cover the existing simple podcast behavior with tests.
+* Add an `enclosure` field to [[plugins/meta]] that expands the
+  given [[ikiwiki/WikiLink]] to an absolute URL (feed enclosures
+  pretty much need to be, and the reference feeds I've looked at
+  all do this).
+* Write failing tests for the desired single-page and inlined
+  HTML behavior, then make them pass by adding enclosure stanzas
+  to `{,inline}page.tmpl`.
+* Write failing tests for the desired RSS/Atom behavior, then make
+  them pass via changes to `{atom,rss}item.tmpl` and [[plugins/inline]].
+* Match feature-for-feature with
+  [tru_podcast](http://www.rainskit.com/blog/542/tru_podcast-a-podcasting-plugin-for-textpattern)
+  (what [[schmonz]] will be migrating from).
+* Enrich [feed metadata](http://cyber.law.harvard.edu/rss/rss.html)
+  by catching up `rsspage.tmpl` to `atompage.tmpl`.
+* Verify that [[plugins/more]] plays well with fancy podcasts.
+* Verify that the feeds validate.
+* Subscribe to a fancy feed in some common podcatchers and verify
+  display details against a reference podcast.
+
+### Status
+
+[[!table data="""
+Feature            |iTunes RSS|iTunes Atom|Downcast RSS|Downcast Atom
+Feed image         |{X}       |{X}        |{X}         |{X}
+Feed title         |(./)      |(./)       |(./)        |(./)
+Feed publisher     |{X}       |{X}        |{X}         |{X}
+Feed "category"    |{X}       |{X}        |{X}         |{X}
+Feed date          |(./)      |(./)       |(./)        |(./)
+Feed description   |(./)      |(./)       |(./)        |{X}
+Episode image      |{X}       |{X}        |{X}         |{X}
+Episode title      |(./)      |(./)       |(./)        |(./)
+Episode date       |(./)      |(./)       |(./)        |(./)
+Episode duration   |{X}       |{X}        |{X}         |{X}
+Episode author     |{X}       |{X}        |{X}         |{X}
+Episode description|(./)      |(./)       |(./)        |{X}
+Episode enclosure  |(./)      |(./)       |(./)        |(./)
+"""]]
+
+### Must-have (for [[schmonz]], anyway)
+
+* Think carefully about...
+    * UTF-8.
+    * Whether [[tips/howto avoid flooding aggregators]] suffices for
+      migrating a fancy podcast into ikiwiki.
+* Verify that _all_ the tests pass (not just my new ones).
+
+-----
+
+## Future improvements
+
+### iTunes fancy podcasting
+
+* [iTunes-specific tags](https://www.apple.com/itunes/podcasts/specs.html)
+  appear to be RSS-only
+    * If they work in Atom, teach `inline` to optionally iTunesify RSS/Atom.
+    * Else, add `itunes` as a third kind of feed (RSS plus more stuff).
+* Notable tags for feeds:
+    * `itunes:subtitle`
+    * `itunes:author`
+    * `itunes:summary` (same as `description`)
+    * `itunes:owner` (includes `itunes:name` and `itunes:email`)
+    * `itunes:image href=''`
+    * `itunes:publisher`
+    * `itunes:category text=''` (can contain subcategories)
+    * `itunes:keywords`
+* Notable tags for entries:
+    * `itunes:duration`
+        * [[!cpan Audio::TagLib]] might be fastest, if present and applicable
+        * [ffprobe](http://ffmpeg.org/ffprobe.html) is reasonably fast
+        * [mediainfo](http://mediainfo.sourceforge.net/) is way slower
+        * Cache computed durations as pagestate
+
+### Fancy podcast aggregating
+
+* Write tests comparing a fancy podcast (HTML and feeds) against
+  the same podcast aggregated and republished, then make them pass
+  via changes to `aggregatepost.impl` and [[plugins/aggregate]].
+
+### Other ideas
+
+* Optionally specify the enclosure's:
+    * MIME type, in case `File::MimeInfo` guesses wrong.
+    * Duration, in case `ffprobe` guesses wrong.
+* Optionally specify enclosures outside the wiki:
+    * Some people don't want to store big unchanging files in the VCS.
+    * Other people like [podcasting found media](http://huffduffer.com/about).
+    * We'd have to download the file just to compute some metadata
+      about it, and then somehow not frequently re-download it.
+* Configurably generate additional subscription links (such as
+  iTunes) alongside the RSS/Atom ones in [[plugins/inline]].
+* Support Apple's "enhanced podcasts" (if they're still relevant).
diff --git a/doc/todo/hook_to_detect_markdown_links_to_wiki_pages.mdwn b/doc/todo/hook_to_detect_markdown_links_to_wiki_pages.mdwn
new file mode 100644
index 000000000..ad9c7dda4
--- /dev/null
+++ b/doc/todo/hook_to_detect_markdown_links_to_wiki_pages.mdwn
@@ -0,0 +1 @@
+For an internal wiki, we occasionally get patches that link to internal wiki pages using the Markdown link syntax.  I'd love to see an optional git hook to detect that and complain.
diff --git a/doc/users/schmonz.mdwn b/doc/users/schmonz.mdwn
index fc7558b24..10ca6e6eb 100644
--- a/doc/users/schmonz.mdwn
+++ b/doc/users/schmonz.mdwn
@@ -2,7 +2,7 @@
 for all sorts of things. His attempts at contributing:
 
 [[!map
-pages="!*/Discussion and ((link(users/schmonz) and plugins/*) or rcs/cvs)"
+pages="!*/Discussion and ((link(users/schmonz) and plugins/*) or rcs/cvs or todo/fancypodcast)"
 ]]
 
 He's also written a plugin for [WIND