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

doc/bugs/removing_pages_with_utf8_characters.mdwn

@@ -0,0 +1,18 @@
+I have a page with the name "umläute". When I try to remove it, ikiwiki says:
+
+Error: ?umläute does not exist 
+
+I wrote the following patch, which seems to work on my machine. I'm running on FreeBSD 6.3-RELEASE with ikiwiki-3.20100102.3 and perl-5.8.9_3.
+
+    --- remove.pm.orig      2009-12-14 23:26:20.000000000 +0100
+    +++ remove.pm   2010-01-18 17:49:39.000000000 +0100
+    @@ -193,6 +193,7 @@
+                            # and that the user is allowed to edit(/remove) it.
+                            my @files;
+                            foreach my $page (@pages) {
+    +                               $page = Encode::decode_utf8($page);
+                                    check_canremove($page, $q, $session);
+     
+                                    # This untaint is safe because of the
+
+

doc/plugins/contrib/getfield.mdwn

@@ -18,7 +18,7 @@ use per-page structured data, where each page is treated like a record, and the
 structured data are fields in that record.  This can include the meta-data for
 that page, such as the page title.
 
-This plugin is meant to be used in conjunction with the B<field> plugin.
+This plugin is meant to be used in conjunction with the **field** plugin.
 
 ### USAGE
 

doc/plugins/contrib/getfield/discussion.mdwn

@@ -0,0 +1,28 @@
+## Templating, and other uses
+
+Like you mentioned in [[ftemplate]] IIRC, it'll only work on the same page. If it can be made to work anywhere, or from a specific place in the wiki - configurable, possibly - you'll have something very similar to mediawiki's templates. I can already think of a few uses for this combined with [[template]] ;) . --[[SR|users/simonraven]]
+
+> Yes, I mentioned "only current page" in the "LIMITATIONS" section.
+
+> What do you think would be a good syntax for querying other pages?
+> It needs to resolve to a single page, though I guess using "bestlink" to find the closest page would mean that one didn't have to spell out the whole page.
+
+>> I don't know the internals very well, I think that's how other plugins do it. *goes to check* Usually it's a `foreach` loop, and use a `pagestate{foo}` to check the page's status/state. There's also some stuff like 'pagespec_match_list($params{page}` ... they do slightly different thing depending on need. --[[SR|users/simonraven]]
+
+>>> No, I meant what markup I should use; the actual implementation probably wouldn't be too difficult.
+
+>>> The current markup is {{$*fieldname*}}; what you're wanting, perhaps it should be represented like {{$*pagename*:*fieldname*}}, or {{$*pagename*::*fieldname*}} or something else...
+>>> -- [[KathrynAndersen]]
+
+>>>> Oh. Hmm. I like your idea actually, or alternately, in keeping more with other plugins, doing it like {{pagename/fieldname}}. The meaning of the separator is less clear with /, but avoids potential issues with filename clashes that have a colon in them. It also keeps a certain logic - at least to me. Either way, I think both are good choices. [[SR|users/simonraven]]
+
+>>>>> What about using {{pagename#fieldname}}? The meaning of the hash in URLs sort of fits with what is needed here (reference to a 'named' thing within the page) and it won't conflict with actual hash usages (unless we expect different named parts of pages to define different values for the same field ...)
+>>>>> -- [[Oblomov]]
+>>>>>> That's a good one too. --[[simonraven]]
+
+
+> I'm also working on a "report" plugin, which will basically apply a template like [[ftemplate]] does, but to a list of pages given from a pagespec, rather than the current page.
+
+> -- [[users/KathrynAndersen]]
+
+>> Ooh, sounds nice :) . --[[SR|users/simonraven]]

doc/plugins/po.mdwn

@@ -132,6 +132,8 @@ lighttpd
 Recent versions of lighttpd should be able to use
 `$HTTP["language"]` to configure the translatted pages to be served.
 
+See [Lighttpd Issue](http://redmine.lighttpd.net/issues/show/1119)
+
 TODO: Example
 
 Usage

doc/todo/svg.mdwn

@@ -3,6 +3,7 @@ We should support SVG.  In particular:
 * We could support rendering SVGs to PNGs when compiling the wiki.  Not all browsers support SVG yet.
 
 * We could support editing SVGs via the web interface.  SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
+  * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated -- [[EricDrechsel]]
 
 --[[JoshTriplett]]
 

doc/users/Oblomov.mdwn

@@ -0,0 +1 @@
+Getting started with Ikiwiki, like the git backend a lot, would like to see a dynamic version of it.

doc/users/ericdrechsel.mdwn

@@ -0,0 +1 @@
+[My homewiki profile](http://wiki.shared.dre.am/people/eric/)